https://www.youtube.com/watch?v=996OiexHze0

OAuth2.0

<aside> 💡

OAuth2.0은 Client 애플리케이션에게 자신의 리소스에 제한된 접근을 허용할 수 있도록 하는 인가 프로토콜이다.

</aside>

OAuth2.0의 등장 배경

<aside> 💡

아래에서 언급되는 ‘서비스’는 OAuth2.0 컨텍스트에서는 Client이다.

</aside>

어떤 서비스(Client)에서 구글 로그인을 지원할 때, 구글 로그인한 사용자(Resource Owner)의 연락처 목록에 접근할 필요가 있다고 가정해보자. OAuth2.0이 없다고 한다면, 사용자(Resource Owner)가 그러하듯 이 서비스(Client)도 구글에 사용자(Resource Owner)의 아이디와 비밀번호로 로그인하여 사용자의 연락처 정보를 조회해야 할 것이다. 즉, 서비스(Client)가 사용자(Resource Owner)의 비밀번호를 요구하게 된다.

당연하게도, 이런 방식은 실서비스에서 사용될 수 없다. 따라서 사용자(Resource Owner)가 서비스(Client)에 자신의 구글 비밀번호를 제공하지 않고도 서비스(Client)에게 자신의 구글 연락처에 접근할 수 있도록 허용해주는 프로토콜이 필요했고, 이것이 OAuth2.0이 등장한 배경이다.

OAuth2.0의 동작원리

사용자(Resource Owner)의 구글 비밀번호는 오직 사용자만 알아야 하기 때문에, 구글에 로그인하는 것도 오직 사용자(Resource Owner)여야만 한다. 따라서 서비스(Client)는 사용자(Resource Owner)가 직접 구글에 로그인할 수 있도록 인터페이스를 제공하고, 이 과정에서 구글의 자원에 접근하는데 대한 동의를 구한다. 이것을 구체적으로 표현한 시퀀스 다이어그램은 다음과 같다.

sequenceDiagram 
	box blue FrontChannel
		participant Client
		participant Google
		participant Resource Owner
	end
	box red BackChannel
		participant Client's Server
		participant Google's Authorization Server
		participant Google's Resource Server
	end
  Client->>Resource Owner: '구글 로그인'과 같은 인터페이스 제공
  Resource Owner ->> Google: 구글 페이지로 리다이렉트되어 로그인
  Google->>Resource Owner: Client 애플리케이션이 Scope에 해당하는 자원에 접근하는 것에 동의를 구함
  Resource Owner->>Google: 동의
  Google->>Client: 사전에 약속된 redirect uri 혹은 callback 경로로 리다이렉트됨. 이때 uri에 일종의 티켓인 code가 포함됨(OAuth2.0 컨텍스트 상 Authorization Grant)
  Client->>Client's Server: 구글로부터 발급받은 티켓인 code를 자신의 서버로 전달
  
  Client's Server-->Google's Authorization Server: 클라이언트가 사전에 구글로부터 발급받은 자신의 비밀키와 함께 code를 제출
  Google's Authorization Server-->Client's Server: 클라이언트가 권한이 있다면, access token 발행
  Client's Server-->Google's Resource Server: 구글의 인가 서버로부터 발급 받은 access token을 제출하여 자원에 접근

     

OpenID Connect

OAuth2.0에서 서비스(Client)가 사용자(Resource Owner)로부터 얻을 수 있는 건 자원에 대한 접근 권한이지, 사용자의 신원(ID)은 보장되지 않는다. 만약 Scope에 사용자의 신원 정보를 포함할 수 있다면, 해당 방법으로 우회하여 인증을 구현할 수는 있지만 어디까지나 우회안에 불과하다. OpenID Connect는 이러한 인증 문제를 해결하기 위해 OAuth2.0을 확장한 프로토콜이다.

OpenID Connect의 동작원리

OAuth2.0상에서 Scope에 openid 를 포함시키면, 구글의 인가 서버로부터 access token뿐만 아니라, ID token도 받을 수 있다. ID token은 JWT 형식의 토큰으로, 내부에 사용자의 ID 정보(ex: email, name 등)가 포함되어 있으며, 이 토큰을 검증하거나 복호화함으로써 클라이언트는 사용자의 신원을 안정하게 확인할 수 있다.

Understanding OAuth 2.0 and OpenID Connect