OpenID Connect와 OAuth2.0

wlsh44·2023년 2월 12일

OAuth

목록 보기

2/2

OpenID Connect란

OpenID Connect(OIDC)는 OAuth 2.0을 기반으로 만들어진 유저의 인증(Authentication)에 초점을 맞춘 프로토콜입니다. OIDC를 통해 유저는 타사 애플리케이션(클라이언트)에서 구글, 페이스북 등의 계정으로 인증이 가능해지고, 유저에 대한 기본적인 정보를 제공받을 수 있습니다.

OIDC 흐름

OIDC는 OAuth 2.0을 기반으로 만들어졌기 때문에 기본적인 흐름은 OAuth 2.0과 완전히 동일합니다. 다만 마지막에 access token과 함께 ID token을 추가로 제공하는 부분에서 차이가 발생합니다. 이 ID token을 통해 유저의 간단한 정보들이 담겨있고, 클라이언트는 이 토큰을 통해 유저를 인증하거나 간단한 프로필을 제공할 수 있습니다. 또한 OAuth 인증을 통해 발급된 access token을 통해 접근 권한이 있는 리소스에 대한 요청도 할 수 있습니다.

ID token

ID token은 JWT의 형식으로 전달됩니다. Playload를 살펴보면 크게 다음과 같은 내용들이 담겨 있습니다.

aud: Client ID
sub: 리소스 서버 내의 유저 식별자
iss: 토큰 발급자(IDP, ID Provider)
iat, exp: 토큰 발급 및 만료 시간

이 외에도 아래의 카카오 ID token의 예시처럼 이메일이나 프로필처럼 미리 설정한 scope의 정보들이 담겨있습니다.

이때 ID token에서 중요한 점은 토큰에 담을 scope의 범위가 profile, email, address, phone 으로 정해져 있다는 점입니다. (scope 공식 문서) 그리고 Playload에 담는 Claims의 이름도 표준화했기(ex nickname, email, picture 등, 표준 Claims 공식 문서) 때문에 OIDC를 사용하는 여러 서비스들의 규격을 하나로 통일할 수 있다는 장점이 있습니다.

OAuth 2.0과 OIDC

OIDC가 OAuth 2.0을 기반으로 만들어졌지만, OAuth가 로그인 기능과 같이 인증의 용도로 사용되거나 인증과 인가 모두 OAuth의 기능으로 혼용해서 부르는 경우가 많기 때문에 처음 두 기술의 차이점을 공부할 때 어려움을 많이 겪는 것 같습니다.

OAuth와 OIDC의 차이점을 말할 때 항상 OAuth는 인가(Authorization), OIDC는 인증(Authentication)이라는 말이 빠지지 않습니다. 즉, OAuth는 리소스의 API를 이용할 수 있는 권한을 얻는 기술이고, OIDC는 해당 유저의 신원을 검증하는 기술이라는 차이가 있습니다. 하지만 OAuth도 권한을 얻기 위해 로그인을 해야 하니까 유저를 인증하는 과정을 포함하고 있기 때문에 차이가 없다고 느낄 수도 있습니다. 이는 두 프로토콜의 리턴값을 보면 어떤 부분에 중점을 두었는지 알 수 있습니다.

OAuth는 인증에 성공한 유저에게 리소스에 대한 접근 권한인 access token만을 제공합니다. 물론 토큰의 만료 시간, scope, refresh token 등의 정보도 포함되어 있지만 여기에 있는 어떤 필드에도 유저에 대한 정보는 존재하지 않습니다. 마치 호텔이나 회사에서 제공하는 임시 출입증과 같은 셈이죠. 그래서 OAuth를 통해 유저의 정보를 얻기 위해서는 access token을 얻은 후에 다시 해당 토큰을 가지고 유저의 정보를 요청하는 작업을 해야합니다.

이런 OAuth의 단점때문에 생긴 프로토콜이 바로 OIDC입니다. OIDC 인증을 통해 발급된 ID token에는 유저의 프로필, 이메일 등 민감하지 않은 정보들이 포함될 수 있습니다. 이때문에 소셜 프로필을 기반으로 회원 정보를 저장하는 애플리케이션일 경우 리소스 서버에 특별히 리소스를 요청하지 않아도 되기 때문에 요청의 수를 절반 이하로 줄일 수 있습니다.

단순히 네트워크 요청량을 줄이는 점에서도 좋지만 사실 OAuth는 인증의 목적으로 사용하게 됐을 때의 여러 결함이 있습니다.

클라이언트가 access token의 실제 대상(audience)이 아니기 때문에 위에서 발생한 문제처럼 클라이언트가 유저의 어떠한 정보도 알지 못합니다.
리소스 서버와 유저간의 연결이 없기 때문에 리소스 서버 입장에서는 실제로 토큰이 인증을 한 유저와 함께 있는지를 알 수 없습니다.
access token을 얻기 위해서는 인증이 필요하기 때문에 인증의 근거로 생각할 수도 있지만, 2와 같은 이유로 인증의 근거로 사용하기 어렵습니다. 또한 access token은 항상 인증을 해야만 얻을 수 있는게 아니라 refresh token 등을 통해서도 얻을 수 있다는 문제점도 있습니다.
OAuth는 audience를 제한하는 기능이 없기 때문에 단순 로그인의 용도라면 어떤 클라이언트에서 발급받은 access token을 다른 클라이언트에서도 사용할 수 있게 됩니다. 다른 클라이언트는 해당 토큰이 본인이 발급받은 토큰인지, 외부에서 발급된 토큰인지 파악할 수 없기 때문입니다.

이 외에도 여러가지 문제점이 OAuth 공식 홈페이지에 적혀있습니다. (oauth.net)

OIDC의 ID 토큰은 JWT 기반이며, ID token 내부에 어떤 유저의 토큰인지, 발급 대상(audience)은 어떤 클라이언트인지 등이 포함되어있기 때문에 이런 문제점을 해결할 수 있습니다.

둘의 차이를 단순하게 요약하자면 다음 표와 같다고 할 수 있을 것 같습니다.

	OAuth 2.0	OIDC
용도	인가(Authorization)	인증(Authentication)
내용	access token(리소스 접근용, 유저 정보x)	access token + ID token(인증용, 유저 프로필 정보 등)
예시	API 이용 권한(구글 캘린더 등)	소셜 로그인