저번 글에 이어서 인증 밀 인가에 대한 개념을 정리해보자. 이번 타겟은 OpenID Connect(OIDC) 이다.
우리의 삶 속에서 "인증"은 무엇이 있을까? COVID-19 로 인해 우리는 어딜 들어가더라도 방문 기록을 남기게 되었다. 필자는 KAKAO의 QR 체크인 기능을 이용한다. 핸드폰을 흔들면 instant한 QR 코드를 받고, 이걸 들이미는 것은 곧 "나"라는 존재가 여길 왔다 갔음을 인증한다. 이외에도 우리는 여권이나 주민등록증, 운전면허증을 내밂으로써 "나"라는 존재를 인증하곤 한다.
QR 체크인과 나머지 3가지 (여권 등)의 차이는 지속 시간의 차이일 뿐이고 인증을 한다는 것에서는 차이가 없다. 그렇다면 인터넷 속에서 "나"는 어떻게 인증되고 있는가?
이같은 편의성은 IDP(IDentity Provider)라 불리는 신원확인 서비스가 제공한다. IDP는 SAML(Security Assertion Markup Language), OAuth 2.0, OIDC(OpenID Connect) 같은 표준을 기반으로 사용자를 인증하거나 특정 리소스를 이용하도록 허가 또는 관리한다.
사실 SAML, OAuth 1.0a, OAuth 2.0, OIDC 가 무엇인지 다 공부하고 쓰려고 했는데 너무 어려워서 올바르게 적을 자신이 없다. 그래서 당장 OIDC를 회사에서 써야 하니까 기반이 되는 OAuth 2.0부터 이해해보자.
필자가 위의 그림을 통해 이해한 시나리오는 다음과 같다.
위의 OAuth Architecture로 치면, Resource Server는 google 내부의 게임 정보 저장 공간, Authorization Server는 google auth api, Client는 게임 client라고 생각하면 된다. 게임 Client는 유저의 게임 정보를 google storage에 저장하려고 하는데, 이 때 현재 유저만의 저장소에 저장해야 하기 때문에 인증 및 인가가 필요한 것이다. 우리는 최초의 로그인을 통해 "인증"을 성공하고, 이 때 받은 Access Token을 이용해서 이후의 모든 저장에 대한 "인가"를 받는다고 생각하면 될 것 같다! 모바일 게임의 경우는 이 token이 refresh 되는 경우는 드문 것 같다.
머리가 어질어질하다. 다음에 계속...
http://yoophi.github.io/translations/oauth_openid_connect_saml.html