Google 로그인 등에 사용되는 OIDC(OpenID Connect)는 OAuth2.0 프로토콜을 기반으로 하고 있습니다.

OAuth 2.0이 인증만 제공하는 반면, OIDC는 인증 기능을 추가하여 사용자 인증 및 인증 시나리오에 대한 보다 표준화된 솔루션을 제공합니다.

간단히 말해: OIDC = 인가 프로토콜 + 신원 인증 프로토콜 입니다.

OIDC의 등장 배경

여러 서비스가 생겨나고 각 서비스는 각자 사용자 정보를 관리하게 됩니다.

하지만, 여러 보안 사고로 각 서비스에 저장된 사용자들의 정보가 유출되는 사고가 발생하고 이에 각 서비스 제공자들은 사용자 정보를 관리하는 것에 큰 부담을 느끼게 됩니다.

사용자들도 각 서비스마다 인증정보를 각각 저장해야하는 부담이 있었고, 이 또한 보안 사고로 이어지기 쉬웠습니다.

따라서 신뢰할 수 있는 서비스에 사용자의 정보 관리와 인증 절차를 위임하고 그 정보를 토대로 각 서비스에서 사용자의 정보를 조회할 수 있도록 하면 보안 문제를 해결할 수 있겠다는 니즈가 있었습니다.

이 문제를 해결하기 위해 등장한 것이 OpenID Foundation에서 추진하는 개방형 표준 및 분신 인증 프로토콜 OpenID Connect(OIDC)입니다.

OIDC는 기존 OpenID 프로토콜의 3세대 프로토콜로서 OAuth2.0을 기반으로 하고 있습니다.

OpenID4

현재는 OIDC를 기반으로 하는 OpenID4VC, OpenID4VP라는 새로운 표준이 발표되었습니다.

ref - OpenID4VC

OAuth 2.0과 OIDC

사실 OAuth 2.0으로 다른 서비스로 부터 사용자의 정보를 가져올 수 있는 것 같습니다.

하지만, OAuth 2.0은 인가(Authorization)에 관한 프로토콜이고 인증(Authentication)에 관한 내용이 아닙니다.

결론부터 말씀드리면, OAuth 2.0은 액세스 토큰(Access Token)을 발급받는 프로토콜이고, OIDC는 인가받은 권한을 바탕으로 사용자의 정보를 가져오는 즉, 인증하는 프로토콜 입니다.

인가(Authorization)과 인증(Authentication)

먼저 인증과 인가 헷갈리는 용어부터 살펴보겠습니다.

인가(Authorization)

인가는 권한을 부여하는 과정으로 "너 뭐 할 수 있어?"를 결정하는 절차입니다.

인증(Authentication)

인증은 사용자 신원 확인 단계로 "너 누구야?" 라고 물어보는 것이 인증입니다.

OAuth 2.0 정리

OAuth 2.0은 "인가(Authorization)"에 관한 프로토콜로 Resource Owner(사용자)가 Client(서비스)에게 권한을 부여하는 과정입니다.

Resource Owner(사용자)는 Authorization Server(Google 등의 인증 서버)에게 자신의 신분을 "인증"하고 Client(서비스)에게 Resource Server(Google 등의 정보 서버)로부터 자신의 정보에 접근할 수 있는 권한을 "인가"하는 과정입니다.

여기서 "인가"받은 권한은 Access Token으로 발급되어 표현됩니다.

따라서, 인가받은 권한으로 Resource Server로부터 사용자의 정보를 가져올 수 있지만 여기서 발생한 문제로 OIDC가 필요해집니다.

OIDC vs OAuth 2.0

OIDC는 OAuth 2.0의 어떤 불편를 해결했는지 알아보겠습니다.

Client가 필요한 것은 사용자의 정보

Client가 OAuth 2.0 과정을 통해 얻고 싶은 것은 보통 사용자의 정보입니다.

Access Token을 얻어 Resource Server에 접근하여 사용자의 정보를 조회할 수 있지만, 번거롭습니다.

제각각의 Access Token 형태

OAuth 2.0에선 인가 받은 권한을 반드시 String 형태로 전달하도록 되어 있습니다.

따라서, Access Token의 형태는 매우 다양한 형태로 전달할 수 있습니다.

- WS-Security Token Profile

- SAML Tokens

- JWT Tokens

- LEGACY Tokens...(ORACLE ACCESS MANAGER, SITEMINDER, etc)

- Custom Tokens...

이는 서비스가 vendor마다 형태에 맞게 대응하게 강요하기 때문에 매우 복잡합니다.

OIDC

OIDC는 OAuth 2.0의 흐름을 지키면서 ID Token이라는 개념을 도입해 이러한 문제를 간단히 해결합니다.

- 먼저 Authorization code를 만드는 흐름에서 SCOPE로 "OPENID PROFILE"이라는 값을 추가하여 OIDC 인증 절차임을 명시합니다.

- 그렇게 redirect되어 Resource Owner(사용자)와의 인증 절차를 거치고 나면 사용자에게 Authorization Code를 받습니다.

- Client는 Authorization Code와 Client ID, Client Secret을 제출하여 Access Token을 발급받으며, 이 때 ID Token도 함께 발급받습니다.

- Client는 ID Token을 통해 사용자 정보를 확인할 수 있습니다. (즉, 사용자가 누구인지 "인증"하게 된 것입니다.)

- 추가적인 정보가 필요하면 OIDC 프로토콜에 따른 별도의 "Userinfo Endpoint"를 통해 조회할 수 있습니다.

OIDC의 장점

OIDC는 OAuth 2.0 과정을 통해 필요한 사용자의 정보가 필요한데, Access Token과 함께 ID token을 함께 발급해 줌으로서 불필요한 요청을 줄였습니다.

- AccessToken 요청 -> AccessToken -> Resource Server에 접근 -> 사용자 정보 조회

- AccessToken + ID Token 요청 -> ID Token -> 사용자 정보 조회

이렇듯 불필요한 요청을 반으로 줄였습니다.

OIDC의 특징

1. 상호운용성

인증 서비스는 기본적으로 다양한 컨슈머 서비스들이 사용할 수 있도록 상호운용성을 반드시 충족해야 합니다. OIDC 또한 표준영역(openid, profile, email, address, phone)에 대해 요청 시 필요한 사용자 정보들을 ID 토큰을 통해 제공할 수 있습니다.

2. 단순성, 모바일 지향 형식

JSON(Javascript Object Notation) 기반의 REST 친화적인 구조를 채택하여 손쉽게 사용할 수 있습니다.

3. 보안

ISO/IEC 29115 Entity Authentication Assurance 프레임워크의 레벨 1~4를 선택할 수 있습니다. 레벨이 높을수록 인증 시 PIN과 같은 추가적인 정보를 요구할 수 있습니다. [그림 1]에서 'Sign in with Google'을 통해 인증할 경우 추가적으로 인증번호를 물어오는데 이는 레벨 2를 지정하여 사용하는 것으로 유추됩니다.

4. 유연성

OP에 직접 요청을 할 수 있는 Normal 타입, JWT를 이용하여 서명된 데이터 소스를 모두 OP를 통해 전달하는 Aggregated 타입, 데이터 소스를 RP(Relying Party)에서 직접 Access 토큰을 사용하여 전달받는 Distributed 타입이 있으며, 이 중 하나가 아닌 여러 타입을 결합한 하이브리드 형태로도 사용할 수 있습니다.