이번 글에서는 OpenID Connect에 대해서 알아보겠습니다.
정의
OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.
위는 OpendID Connect 공식 문서에서 정의한 OpenID Connect의 정의입니다.
간략하게 위 내용을 요약하면 다음과 같습니다.
OpendID Connect는 OAuth 2.0 프로토콜을 기반으로 하는 간단한 identity layer이다. 인가 서버에서 수행되는 인증을 기반으로 End-User의 신원을 검증하게 해줄 뿐만 아니라, 상호운용성 있고 REST-like 한 방식 아래 기본 프로필 정보들을 획득 할 수 있게 도와준다.
OAuth 2.0 프로토콜을 기반으로 하는 만큼 추상적인 개념 즉, 확장성 있는 구조를 가지고 있기에 이 글에서는 OAuth 2.0과의 차이점(확장된 부분)을 중점적으로 살펴보겠습니다.
ID Token
OAuth2와 가장 큰 차이점이라고 한다면, 바로 ID Token의 존재입니다. ID Token의 정의는 다음과 같습니다.
The primary extension that OpenID Connect makes to OAuth 2.0 to enable End-Users to be Authenticated is the ID Token data structure. The ID Token is a security token that contains Claims about the Authentication of an End-User by an Authorization Server when using a Client, and potentially other requested Claims. The ID Token is represented as a JSON Web Token (JWT).
간단하게 위 내용을 요약하면 다음과 같습니다.
- OAuth2를 기반으로 해서 만들어진 주요한 확장점이다.
- 인가 서버에서 사용자를 인증한 Claim들을 담고 있는 토큰이다.
- JWT로 구성된다.
위 내용만 본다면, ID Token의 필요성을 느끼지 못할 수 있습니다. 또한 그 용도도 불투명합니다. 이 글을 읽어보신다면 충분히 ID Token의 용도와 필요성을 느끼실 거라고 생각합니다.
Token Endpoint Response
Authorization Code Flow를 사용한다고 가정 했을 때, 기본적인 Flow는 OAuth2와 큰 차이점이 없습니다. 하지만 Token Enpoint에 요청을 보낸 후 받은 Response에는 차이점이 존재합니다. 아래는 OpenID Connect에서 Token Endpoint에 요청을 보내고, 요청이 성공적으로 검증되었을 때 받는 Response의 예시 구조입니다.
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache {
"access_token": "SlAV32hkKG",
"token_type": "Bearer",
"refresh_token": "8xLOxBtZp8",
"expires_in": 3600,
"id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjFlOWdkazcifQ.ewogImlzc
yI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwKICJzdWIiOiAiMjQ4Mjg5
NzYxMDAxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiAibi0wUzZ
fV3pBMk1qIiwKICJleHAiOiAxMzExMjgxOTcwLAogImlhdCI6IDEzMTEyODA5Nz
AKfQ.ggW8hZ1EuVLuxNuuIJKX_V8a_OMXzR0EHR9R6jgdqrOOF4daGU96Sr_P6q
Jp6IcmD3HP99Obi1PRs-cwh3LO-p146waJ8IhehcwL7F09JdijmBqkvPeB2T9CJ
NqeGpe-gccMg4vfKjkM8FcGvnzZUN4_KSP0aAp1tOJ1zZwgjxqGByKHiOtX7Tpd
QyHE5lcMiKPXfEIQILVq0pc_E2DzL7emopWoaoZTF_m0_N0YzFC6g6EJbOEoRoS
K5hoDalrcvRYLSrQAZZKflyuVCyixEoV9GfNQC3_osjzw2PAithfubEEBLuVVk4
XUVrWOLrLl0nx7RkKU8NXNHq-rvKMzqg"
}
앞서 정의한 대로, id_token은 JWT의 구조를 가지고 있습니다.
참고로, Access Token의 경우 JWT의 구조를 가질 수도 있고 아닐 수도 있습니다.
주의점
앞서 언급한 이 글에서 쉽게 주의할 점에 대해 학습할 수 있습니다. 간략하게 주의점을 요약하면 다음과 같습니다.
- ID Token을 API 호출 용도로 사용해서는 안됩니다.
- ID Token을 통해 Client의 접근 권한을 확인해서는 안됩니다.
ID Token은 사용자에 대한 인증 정보입니다. 따라서 API 호출의 경우 Access Token을 통해 수행해야 합니다. 물론 상황에 따라 ID Token의 이동이 필요할 수도 있겠지만 기본적으로는 허용되지 않습니다.
마무리하며
이번 글에서는 OpenID Connect에 대해 알아보았습니다. OAuth2를 기반으로 하는 만큼 확장성 있고 유연한 프로토콜이므로 사용에 제한이 크게 없습니다. 다만, 인증과 인가에 관련된 프로토콜인 만큼 여러 정보에 대한 보안 설계가 꼭 필요하다고 생각합니다.
