우리는 종종 블로그에서
많은 것을 파악할 수 있습니다
혹은 친구들이나 인터넷에서 OpenID가 OAuth 2.0 구조물보다
더 낫다는 이야기를 들은 적이 있을 것입니다
따라서 요즘 많은 사람들은
OpenID Connect 혹은 줄임말로 OIDC로
불리는 것에 대해 이야기를 나눕니다
대다수가 OAuth 2.0대신 OpenID를 사용하라고 하겠죠
따라서, 여러분들은 여러가지 의문점을 가질 수 있습니다
OAuth 2.0과 OpenID 연결의 차이는 무엇인지
별개의 두 가지 구조물이 있는 건지
둘 중에 어떤 것을 사용하는 것이 좋을지와 같은 질문들 말이죠
"OpenID가 더 낫다면 이 강의자는 왜 자꾸
OAuth 2.0 구조물에 대해 이야기하는 거야?"라고 생각하실 겁니다
여러분이 많은 의문점을 가지고 계신다는 것을 알고 있습니다
그래서 이번 강의의 몇 분 정도는, OpenID 연결과
OAuth 2.0 구조물을 비교하며
알아보려고 합니다
우리가 승인을 얻을려면
정말 승인이 필요한 상황이여야 합니다
그리고 OAuth 2.0 구조물을 사용할 때마다
액세스 토큰을 받게 될 것이고
액세스 토큰의 발급에 따라 스코프를 받게 될 것입니다
이러한 액세스 토큰과 스코프를 통해
승인을 강화할 수 있습니다
클라리언트 애플리케이션에서 엔드 유저에 대한
허가를 이해할 수 있는 것이죠
하지만 블로그 애플리케이션이나 통계 웹 애플리케이션과 같은
대부분의 웹 애플리케이션이
승인 이메일 주소에 대한 계정 정보를
Google, Facebook, GitHub에서 받게 됩니다
이러한 이유로 Twitter 는
인증을 할 때도 OAuth 2.0 구조물을 사용하게 되었습니다
우리가 이전에 웹사이트 Slack에 대해 이야기하면서
OAuth 2.0 플로우가 구글 로그인과
함께 작동하여 도움이 되는 것을
보여주고 있습니다
OAuth 2.0 구조물과 동일하게, 승인과 허가를
활용하고 있지만
변경된 구조물로는
액세스 토큰과 스코프 세부 사항을 파악할 수 있습니다
OAuth 2.0 구조물로는 누가 엔드 유저인지
디테일은 무엇인지, 이메일은 무엇인지
주소 세부 사항이 무엇인지 알 수 없습니다
클라이언트 애플리케이션이
OAuth 2.0 구조물을 실행할 때마다 이를 이해하는 것은
불가능합니다
이러한 이유로
OAuth 2.0 구조물 혹은 ES를 사용하고 있는
많은 단체들도
엔드 유저 혹은 리소스 소유자의 정체에 대한
세부 사항을 알고 싶어합니다
이렇기에
모두가 본인만의 스타일로 클라이언트 애플리케이션이나
관리자들에게, 로그인된 상태인
사용자에 대한 정보를 파악하고 보내기 시작하였습니다
그리고 많은 사람들이 다양한 스타일을 개발해냈기 때문에
통일성이 존재하지 않습니다
이 부분에 관해 많은 사람들이 이야기를 나누었고
OpenID 연결이라는 새로운 컨셉을 구안해냈습니다
OpenID가 무엇이냐고요?
이는 OAuth 2.0 구조물 위에서 작동되는
프로토콜입니다
그저 자그마한 OAuth 2.0 구조물의 싸개와도 같습니다
하지만 OAuth 2.0 구조물을 사용하지도 않고
OAuth 2.0 구조물 자체를
인지하지도 못하게 합니다
OpenID 연결을 사용하는 것은 말이 되지 않습니다
그렇기에, 제가 여러분들에게 OAuth 2.0 구조물을
가르치는 것에 많은 시간을 투자한 것입니다
제가 OpenID 연결에 대해 알려드리고자 하는데
OAuth 2.0 구조물은 HTTP 프로토콜 위에
만들어져 있으며
이는 액세스 토큰의 도움을 얻어 승인하는 역할을 합니다
그 위에는 더 작은 층 혹은
프로토콜이 만들어낸 싸개 즉, OpenID 연결이 있습니다
OpenID 연결을 살펴보면
권한과 인증을 모두 받을 수 있습니다
이 부분에서 의문점이 생기실 수 있습니다. 예를 들어
몇 개의 OpenID 연결이 승인이나 사용자 세부 사항에
도움이 될 수 있을지와 같은 질문 말이죠
따라서 우리가 인증 서버 안에 OpenID 연결을
실행시킬 때마다
두 가지 종류의 토큰을 보일 것입니다
하나는 액세스 토큰이고 또 다른 하나는 ID 토큰입니다
물론, 언제나 리프레쉬 토큰이 있을 것이지만
만약 엔드 유저와 관련된 리프레쉬 토큰을 무시한다면
오직 두 가지 토큰이 존재할 것입니다
하나는 액세스 토큰이며 승인을 관리합니다
또 다른 하나는 ID 토큰이며
사용자 세부 사항의 권한을 관리합니다
또 다른 의문점은
OpenID 연결을 어떻게 하면 승인 서버와
함께 시작할 수 있도록 하는지일 것입니다
별도의 특별한 인증 플로우가 있나요?
물론 OR 속이나 OpenID에게만 별도의
특별한 인증 플로우는 없죠
우리가 해야 하는 것은
스코프 안에 OpenID라는 값을 보내야 합니다
인증 서버로 요청에 해당되는
특정한 스코프를 보낼 때
인증 서버는 이를 인지하고 액세스 토큰큰과 ID 토큰을 동시에
보낼 수 있는 능력을 가지고 있습니다
그리고 이 두 가지 토큰들과 함께
새로운 컨셉이 등장했습니다
이 컨셉은 IAM과 접근 관리입니다
이러한 두 가지 토큰들과 함께 저는 엔드 유저의
정보를 식별하고 접근 관리를 강화할 수 있습니다
신원과 접근 관리와 함께
해낼 수 있는 것이죠
보시다시피, IAM이라는 컨셉이 등장하였으며
Okta와 Keycloak과 같은 인증 서버 산업에서
많이 접하셨을 법한 내용입니다
OpenID 연결과 OR two 구조물을 사용하는 산업들은
모두 이 IAM 컨셉을 활용합니다
그들은 이러한 부분을 모두 제공하지만
액세스 토큰을 사용할 건지 혹은 액세스 토큰과 ID 토큰을
모두 사용할 것인지는 저희가 결정합니다
그리고 OpenID 연결이 모든 애플리케이션에 개발되면서
그들은 사용자 디테일을 ID 토큰의 형태로
공유하는 특별한 방법을 고안했다
이에 더해, OpenID 연결 이전에 모두가 느꼈던 한계점이
해결되고 있기 때문에
모두가 OpenID 연결을 사용하고 있는 것입니다
우리가 OpenID 연결을 사용할 때마다
느낄 수 있는 또 다른 강점은 OpenID 프로필, 이메일
그리고 주소와 같은 스코프가 존재한다는 점입니다
이는 엔드 유저의 세부 사항을 이해하기 쉽게 해주며
프로필 세부 사항이나 이메일 세부사항
주소 세부 사항이나 신원에 대해 OpenID 연결에서
지원되는 스코프를 통해 조금 더 쉽게
파악할 수 있습니다
그리고 JWT 토큰 규정에 따라 우리가 OpenID 연결을
사용할 때마다 받는 ID 토큰은
우리가 그 어떤 정보도
JWT 토큰에 저장할 수 있다는 의미를 가집니다
그리고 동시에, OpenID 연결을 사용하는
모든 인증 서버들은
엔드 포인트를 노출합니다
또, 클라이언트 애플리케이션이 언제든지 실행할 수 있는
이름/사용자 정보를 통해 로그인된 사용자를
더 상세하게 이해할 수 있는 시간을 마련합니다
따라서, OpenID 연결과 관련된
또 다른 장점이 있습니다
OpenID 연결과 OR two 구조물의 차이를
모두 파악했기를 바랍니다
저라면 늘 OpenID 연결을 추천할 것 같은데
OpenID 연결이 액세스 토큰과 ID 토큰을 모두 주기 때문입니다
반면에, OR two 토큰만 사용한다면
액세스 토큰만 받게 될 것입니다
하지만 명심하셔야 할 부분은 OR two 구조물이 없다면
OpenID 연결도 없다는 것입니다
OpenID 연결은 OR two 구조물 위에
ID 토큰을 부여하는 아주 작은 싸개로 만들어졌습니다
동일한 효과를 보여드리기 위해
OpenID 연결에 데모를 보여드리겠습니다
우리가 다시 playground 웹사이트로 오게 되었습니다
여기에는 OpenID 연결 선택지가 있는데요
이는 인증 유형 플로우는 아니지만
ID 토큰과 액세스 토큰을 얻을 수 있도록 도울 것입니다
이 OpenID 연결을 눌러보겠습니다
첫 번째 단계에서는
재구성하고 요청할 것인데
이 과정에서 제 엔드 유저를
인증 서버 로그인 페이지로 안내할 것입니다
따라서 여기서 보면 허가 코드 인증 유형 플로우를
활용하고 있음을 알 수 있습니다
응답 유형이 코드인 이유이기도 합니다
client_id, redirect_uri가 있고
스코프로 오면 이번에는 사진과 별도로
OpenID도 보내야 하는 것을 알 수 있습니다
만약 우리가 ID 토큰만 필요하거나
프로필 세부 사항과 이메일 세부사항도 필요하다면
OpenID와 함께 프로필이나 이메일과 같은
스코프를 추가적으로 보낼 수 있습니다
이것이 OpenID와 OR two 플로우를 구별할 수 있는
유일한 차이점입니다
'승인하기'를 눌러봅시다
저를 로그인 페이지로 안내하네요
제 사용자명이고요
이름을 붙여넣고 비밀번호로 넘어가고 있습니다
같은 것은 언급하고 로그인 버튼을 누르고 있습니다
허가하기를 누르고 있고요
이번에는 이름, 이메일 주소를 애플리케이션과 함께
공유할 것이라는 걸 밝히고
애플리케이션이 사진에 접근할 수 있도록 합니다
저는 상관하지 않고요
이 로그인하기 버튼을 누르고 있습니다
이 단계에서 우리는
상태값과 함께 승인 코드를 받을 것입니다
이 상태 값이 맞다면
이것을 클릭하고, 이어가도록 할 수 있습니다
이제 액세스 토큰과 ID 토큰에 대한
발급 요청을 할 것입니다
이 POST 요청에서
승인 IP 코드, 클라이언트ID
클라이언트 기밀, URA 이동이 있습니다
그리고 우리가 받은 코드가 어떤 것인지도 알려줍니다
따라서 지금 이 '이어가기' 버튼을 클릭한다면
액세스 토큰과 관련해 시간이 가고있는 것을 볼 수 있습니다
물론 ID 토큰도 받았고요
JWT 토큰의 폼으로 있는
이 ID 토큰을 가지고 이동해보겠습니다
JWT.io라는 웹사이트로 이동할 수 있습니다
여기서, 아까의 ID 토큰을 붙여넣기하면
여기 주제가 있고
이름, 그리고 이메일도 있습니다
이것은 발행자
발행 시간이 언제인지도 나왔습니다
추출 시간은 언제인가요?
이런 개별적인 세부사항을 통해
우리는 손쉽게 이름과 코스의 이메일을
식별할 수 있으며
필요시에는 인증 서버 내에 세부 사항에 대한
특정한 구조를 바꿀수도 있습니다
예를 들어, 핸드폰 번호나 주소를
ID 토큰의 일부분으로 말이죠
따라서, 여러분들이 OpenID 연결에 대해
모르는 게 없으실 것이라고 예상합니다
우리는 OpenID와OR two에
대해 많은 이야기를 나누었습니다
부디 모두들 모르는 부분을 넘어가지 마시길 바랍니다
왜냐하면 이 주제를 바탕으로
앞으로 강의들에서 더 많은 이야기들을
나눌 계획이기 때문입니다
이 부분 설명을 끝으로 이번 강의를 마치겠습니다
그리고 이것이 완전한 이론 부분입니다
저희는 아직 웹 애플리케이션 혹은 UA 애플리케이션 속의
코드를 하나도 바꾸지 않았으며
이러한 이유로 GitHub 리포지터리 내에 업로드한
이 부분에 대한 코드가 존재하지 않는 것입니다
저는 저희가 이 복잡한 주제를 끝냈고
여러분들이 이해를 하셨다는 점에서 기쁩니다
잠시 쉬는 시간을 가지며 푹 쉬시고
저는 돌아오시는 대로 다음 강의에서 뵙겠습니다
수고하셨습니다