OIDC(OpenID Connect)와 OAuth 2.0

OAuth

제작한 서비스를 다른 사람도 이용할 수 있게 권한을 인가(Authorization)하려면 어떻게 해야할까요? 다양한 방법들이 떠오를 것입니다. 실제로 많은 회사들이 서로 다른 인가(Authorization) 방법들을 제공했었고, 개발자들은 서로 다른 방법들을 연동하느라 많은 시간을 사용해야 했습니다.

그러던 중 2006년 블레인쿡, 크리스 메시, 래리 하프 등의 개발자들은 인가(Authorization)에 대한 개방형 표준의 필요성을 느꼈고 OAuth 표준을 개발하여 발표하게 되었습니다. OAuth는 등장 이후로 많은 관심을 받았으며, 2012년에는 IETF OAuth 워킹그룹을 주축으로 더욱 개선된 OAuth 2.0 표준이 만들어졌습니다. 이후로 수많은 기업들이 OAuth 2.0을 채택하여 서비스를 공유하고 있습니다.

여기서 중요한 부분은, OAuth는 인가(Authorization)를 목적으로 개발된 표준이라는 점입니다. 타인에게 접근 권한을 부여하고 허가하는 일련의 과정을 표준화 한 것이죠. OAuth는 내부적으로 아래와 같은 복잡한 단계를 거칩니다. 사용자가 허가할 서비스 범위를 결정하면, 서비스 제공자는 AccessToken을 생성하여 Consumer 앱에 전달하고, Consumer 앱은 AccessToken을 사용하여 서비스에 접근하게 됩니다.

OIDC(Open ID Connect)

OAuth 2.0의 등장으로 수많은 서비스들은 표준화된 방법으로 인터넷 자원을 공유할 수 있게 되었습니다. 하지만 모든 것이 만족스러웠던 것은 아닙니다. OAuth는 인가(Authorization)에는 적합하지만, 사용자가 누구인지 식별하는 인증(Authentication)을 위한 목적으로는 개선의 여지가 있었기 때문입니다.

OAuth 2.0에서 발급되는 AccessToken에는 사용자 정보가 포함되어 있지 않습니다. 따라서 성명이나 이메일 등의 사용자 정보를 알고 싶다면 AccessToken을 사용하여 한 번 더 사용자 정보를 조회해야 했습니다. 만약 하루 방문자가 수천만명에 달하는 서비스라면 이러한 요청을 수천만번 더 해야하는 것이죠.

또 다른 문제로는 AccessToken은 절대 외부에 유출되어서는 안되는 민감한 정보라는 것입니다. 외부에 유출되어선 안되는 AccessToken 대신, 애플리케이션 개발 회사들은 사용자 인증(Authentication)만을 목적으로 하는 독자적인 ID Token을 개발하여 사용해야 했습니다.

이러한 문제를 해결하고자 2014년 OIDC (OpenID Connect) 프로토콜이 만들어졌습니다. OIDC는 사용자 인증(Authentication)을 위한 표준을 정의하고 있으며 위에서 언급한 문제들을 개선하였습니다.

OIDC는 이미 폭넓게 사용 중인 OAuth를 그대로 사용하면서, 사용자 인증(Authentication)에 대한 개선사항을 반영하였습니다. 위 그림처럼 AccessToken과 함께 ID Token을 전달하도록 변경된 것이죠. ID Token에는 사용자 이메일, 아이디 등의 사용자 정보가 포함되어 있습니다. 따라서 AccessToken을 통해 사용자 정보를 조회하던 과정을 생략할 수 있습니다. 또한 상대적으로 외부에 전달해도 안전한 데이터이므로 JWT(JSON Web Token) 등의 사용자 식별자로 사용할 수도 있습니다.

OIDC는 OAuth와 경쟁하는 별개의 서비스가 아닙니다. OAuth가 접근권한을 부여하는 인가(Authorization)에 관한 표준이라면, OIDC는 사용자가 누구인지 식별하기 위한 인증(Authentication)에 관한 개방형 표준을 정의합니다. 또한 OIDC는 OAuth를 기반으로 동작합니다. 따라서 OIDC와 OAuth는 서로 배타적인 관계가 아니라 상호 보완적인 관계를 가집니다.

References

• AccessToken vs ID Token : https://www.c-sharpcorner.com/article/accesstoken-vs-id-token-vs-refresh-token-what-whywhen/
• OIDC와 OAuth : https://www.samsungsds.com/kr/insights/oidc.html
• Authentication과 Authorization : https://blog.naver.com/blog_jigeum/222417390682
• OAuth Wiki Authorization : https://ko.wikipedia.org/wiki/OAuth
• OAuth : https://d2.naver.com/helloworld/24942