OpenID Connect(OIDC) 공식문서 정리

OpenID Connect (OIDC)는 OAuth2.0 프로토콜 위에 있는 간단한 ID 계층으로, OAuth2.0은 인증 프로토콜인 반면 OIDC는 신원 인증 프로토콜로 클라이언트 서비스의 사용자 신원을 인증하는데 사용합니다.

블로그 본문은 OIDC 프로토콜에 대해 알아보기 위해 openid.net 내용 중 앞부분을 번역하고 정리한 내용입니다.
OIDC에 인증은 3가지 종류가 있는데 인증 코드 흐름(Authentication Code Flow)을 사용한 인증을 정리했습니다.
번역 문장을 매끄럽게 표현한 부분과 개념 이해가 충분하지 않은 상태에서 구조가 복잡한 부분은 구글 번역 문장을 사용했습니다.

1 소개

OpenID Connect 1.0은 OAuth 2.0 [RFC6749] 프로토콜 위에 있는 간단한 ID 계층이다.
클라이언트는 Authorization Server에서 수행한 인증 기반으로 최종 사용자의 신원을 확인할 수 있다. 또한 REST방식으로 상호 정보 교환이 가능하게 최종 사용자의 기본 프로필 정보를 얻을 수 있다.

The OpenID Connect Core 1.0 명세는 OpenID Connect 기능의 핵심인 OAuth 2.0 위에 구축된 인증, 최종 사용자의 정보 전달을 위한 Claims의 사용을 정의한다.
또한 OpenID Connect사용 시 보안, 개인 정보 보호 고려사항도 기술한다.

배경으로 OAuth 2.0 Authorization Framework [RFC6749] 및 OAuth 2.0 Bearer Token Usage [RFC6750] 사양은 제3자 애플리케이션이 HTTP 리소스에 대한 제한된 액세스를 얻고 사용하기 위한 일반 프레임워크를 제공한다.
리소스에 액세스하기 위해 액세스 토큰을 얻고 사용하는 메커니즘을 정의하지만 식별 정보를 제공하는 표준 methods는 정의하지 않습니다.
특히, OAuth 2.0 프로파일링 없이 최종사용자의 인증 정보 제공은 불가능하다. 독자는 이러한 사양에 익숙해야 한다.

OpenID Connect는 인증을 OAuth 2.0 인증 프로세스의 확장으로 구현합니다.
이 확장의 사용은 Authorization 요청에 openid scope값을 포함하여 Client가 요청합니다.
수행된 인증에 대한 정보는 ID Token(섹션 2 참조)이라는 JSON 웹 토큰(JWT)에 반환됩니다
OIDC를 구현하는 OAuth 2.0 인증서버는 OpenId 제공자(OPs)로도 불린다.

이 사양은 신뢰 당사자가 권한 부여 엔드포인트(Authorization Endpoint) 및 토큰 엔드포인트(Token Endpoint) 위치를 포함하여 OpenID 공급자에 대한 구성 정보를 이미 획득했다고 가정한다.

마찬가지로 이 사양에서는 신뢰 당사자가 이미 충분한 자격 증명을 얻었고 OpenID 공급자를 사용하는 데 필요한 정보를 제공했다고 가정한다.
이는 일반적으로 OpenID Connect Dynamic Client Registration 1.0 [OpenID.Registration]에 설명된 대로 동적 등록을 통해 수행되거나 다른 메커니즘을 통해 얻을 수 있다.

1-1 용어

Authentication
- 부여된 Identity와 엔티티 사이의 결속에서(바인딩에서) 충분한 신뢰를 얻기위한 프로세스
Authentication Request
- 확장된 파라미터와 OpenID Connect가 정의한 scopes 를 사용하는 OAuth 2.0 인증 요청.
Claim
- 엔티티에 대해 설명하는 정보
Entity
- 문맥안에서 별개로 분리되고 구별되는 존재로 식별되는 것. 최종 사용자는 엔티티의 한 예이다.
Essential Claim
- 사용자가 요청한 특정 태스크에 원활한 권한부여 절차를 보장하기 위해 필요하고 사용자가 지정한 특정 클레임
Hybrid Flow
- Authorization Endpoint에서 Authorization Code가 리턴되는 OAuth2.0 과정에서 어떤 토큰은 Authorization Endpoint에서 리턴되고, 어떤 토큰은 Token Endpoint에서 리턴된다.
ID Token
- 인증 이벤트에 대한 클레임을 포함한 JWT(JSON Web Token). 다른 클레임을 포함할 수 있다.
Issuer Identifier
- 발급자의 확인 가능한 식별자
OpenID Provider (OP)
- 최종 사용자 인증과, 신뢰당사자(RP)에게 인증 이벤트와 최종 사용자에 대한 Claims를 제공할 수 있는 OAuth 2.0 Authorization Server(권한 서버)
Relying Party (RP) : 신뢰당사자
- 최종 사용자 인증과 OpenId 공급자의 Claims를 요청하는 OAuth 2.0 클라이언트 애플리케이션

1-2 The OpenID Connect protocol 개요

+--------+                                   +--------+
|        |                                   |        |
|        |---------(1) AuthN Request-------->|        |
|        |                                   |        |
|        |  +--------+                       |        |
|        |  |        |                       |        |
|        |  |  End-  |<--(2) AuthN & AuthZ-->|        |
|        |  |  User  |                       |        |
|   RP   |  |        |                       |   OP   |
|        |  +--------+                       |        |
|        |                                   |        |
|        |<--------(3) AuthN Response--------|        |
|        |                                   |        |
|        |---------(4) UserInfo Request----->|        |
|        |                                   |        |
|        |<--------(5) UserInfo Response-----|        |
|        |                                   |        |
+--------+                                   +--------+

RP (Client)는 OpenID Provider (OP)에게 요청을 보낸다.
OP는 최종 사용자를 인증하고, 권한을 획득한다.
OP는 ID Token과 보통 access token으로 응답한다.
RP(Client)는 access token과 함께 UserInfo Endpoint에 요청을 보낼 수 있다.
UserInfo Endpoint는 최종 사용자에 대한 Claim을 반환한다.

2 ID Token

OpenID Connect가 최종 사용자가 인증되도록 OAuth 2.0에 만드는 주된 확장은 ID Token 데이터 구조이다.
ID 토큰은 Client를 사용할 때 권한 서버에 의한 최종 사용자 인증에 대한 클레임과 그외 요청 클레임을 포함하고 있는 보안 토큰이다. ID 토큰은 JWT(JSON Web Token)로 표시된다.

2-1 ID 토큰 내의 클레임 목록

ID 토큰 내의 다음 클레임은 OpenID Connect에서 사용하는 모든 OAuth 2.0 흐름에서 사용한다.

REQUIRED
- iss
- sub
- aud
- exp
- iat
OPTIONAL or REQUIRED
- auth_time
  - 최종사용자 인증 발생 시간
nonce
- 클라이언트 세션을 ID 토큰과 연결하고 replay 공격을 완화하는 데 사용되는 문자열 값
- 값은 인증 요청에서 ID 토큰으로 수정되지 않은 상태로 전달된다. ID 토큰에 있는 경우 클라이언트는 nonce 청구 값이 인증 요청에서 전송된 nonce 매개 변수의 값과 동일한지 확인해야 한다. 인증 요청에 있는 경우 권한 부여 서버는 인증 요청에서 전송된 임시 값인 청구 값과 함께 ID 토큰에 임시 청구를 포함해야 한다. 인가 서버는 사용된 nonce 값에 대해 다른 처리를 수행하지 않아야 합니다(SHOULD). noncer값은 대소문자를 구분하는 문자열.
OPTIONAL
- acr
- amr
- azp

2-2 ID Token의 클레임 집합 예시

  {
   "iss": "https://server.example.com",
   "sub": "24400320",
   "aud": "s6BhdRkqt3",
   "nonce": "n-0S6_WzA2Mj",
   "exp": 1311281970,
   "iat": 1311280970,
   "auth_time": 1311280969,
   "acr": "urn:mace:incommon:iap:silver"
  }

3 Authentication

OpenID Connect는 인증을 수행하여 최종 사용자가 로그인을 하거나 사용자가 이미 로그인 했는지 확인한다.
OpenID Connect는 서버에서 수행한 인증 결과를 클라이언트가 신뢰할 수 있도록 안전한 방식으로 Client에게 반환한다.
그러한 이유로 이 경우 Client를 Relying Party(RP)라고 부른다.

인증 결과는 ID Token안에 반환한다. ID Token은 발행자, 식별 주제, 인증 만료 시간같은 정보를 표현하는 클레임을 갖고 있다.

3가지 인증 경로

인증 flow는 ID Token과 access token이 클라이언트에게 어떻게 반환될지 결정한다.

the Authorization Code Flow (response_type=code)
the Implicit Flow (response_type=id_token token or response_type=id_token)
the Hybrid Flow (using other Response Type values defined in OAuth 2.0 Multiple Response Type Encoding Practices (OAuth.Responses)

3가지 인증 흐름의 특성

Property	Authorization Code Flow	Implicit Flow	Hybrid Flow
All tokens returned from Authorization Endpoint	no	yes	no
All tokens returned from Token Endpoint	yes	no	no
Tokens not revealed to User Agent	yes	no	no
Client can be authenticated	yes	no	yes
Refresh Token possible	yes	no	yes
Communication in one round trip	no	yes	no
Most communication server-to-server	yes	no	varies

Authorization Request에 전달한 response_type값이 사용한 인증 흐름을 표현한다.

"response_type" value	Flow
code	Authorization Code Flow
id_token	Implicit Flow
id_token token	Implicit Flow
code id_token	Hybrid Flow
code token	Hybrid Flow
code id_token token	Hybrid Flow

3-1 Authorization Code Flow를 이용한 인증

인증 코드 흐름을 사용할 때 모든 토큰은 Token Endpoint에서 반환됩니다.

인증 코드 흐름은 인증 코드를 클라이언트에 반환하며 클라이언트는 이를 ID 토큰과 액세스 토큰으로 직접 교환할 수 있습니다. 이렇게 하면 사용자 에이전트 및 사용자 에이전트에 액세스할 수 있는 다른 악성 응용 프로그램에 토큰을 노출하지 않는 이점이 있습니다. 인가 서버는 액세스 토큰에 대한 인가 코드(Authorization Code)를 교환하기 전에 클라이언트를 인증할 수도 있습니다. 인증 코드 흐름은 클라이언트와 인증 서버 간에 클라이언트 암호를 안전하게 유지할 수 있는 클라이언트에 적합합니다.

클라이언트와 인증 서버 간에 클라이언트 암호를 안전하게 유지할 수 있는 클라이언트는 어떤 것이 필요한가?

3-1-1 Authorization Code 흐름 단계

클라이언트는 원하는 요청 매개변수를 포함하는 인증 요청(Authentication Request)을 준비합니다.
클라이언트는 권한 부여 서버에 요청을 보냅니다.
권한 부여 서버는 최종 사용자를 인증합니다.
권한 부여 서버는 최종 사용자 동의/권한을 얻습니다.
권한 부여 서버는 Authorization Code와 함께 최종 사용자를 클라이언트로 다시 보냅니다.
클라이언트는 Authorization Code를 사용하여 Token Endpoint에게 응답을 요청합니다.
클라이언트는 response body에 ID 토큰과 액세스 토큰이 포함된 응답을 받습니다.
클라이언트는 ID 토큰의 유효성을 검사하고 최종 사용자의 주체 식별자를 검색합니다.

3-1-2 Authorization Endpoint

Authorization Endpoint는 최종 사용자의 인증을 수행한다.
OAuth 2.0에서 정의한 요청 파라미터와 OpenID Connect에서 정의한 파라미터와 값을 사용해서 인증과 인가를 위해 유저 에이전트를 인가 서버의 Authorization Endpoint에 전송하여 수행된다.

인증 엔드포인트와의 통신은 TLS를 활용해야 합니다. TLS 사용에 대한 자세한 내용은 섹션 16.17 을 참조하십시오 .

3-1-2-1 Authentication Request

인증 요청은 인증 서버에서 최종 사용자를 인증하도록 요청하는 OAuth 2.0 인증 요청입니다.

인가 서버는 인가 엔드포인트에서 RFC2616에 정의된 HTTP GET 및 POST 메서드 의 사용을 지원해야 합니다(MUST). 클라이언트는 HTTP GET 또는 POST 메서드를 사용하여 Authorization Server에 Authorization Request를 보낼 수 있습니다(MAY). HTTP GET 메서드를 사용하는 경우 요청 매개변수는 섹션 13.1 에 따라 URI 쿼리 문자열 직렬화를 사용하여 직렬화됩니다 . HTTP POST 메서드를 사용하는 경우 요청 매개변수는 섹션 13.2 에 따라 Form 직렬화를 사용하여 직렬화됩니다. Section 13.2.

OpenID Connect는 인증 코드 흐름과 함께 다음 OAuth 2.0 요청 매개변수를 사용합니다.

REQUIRED
- scope
- response_type
- client_id
- redirect_uri
RECOMMENDED
- state
OpenID Connect는 또한 OAuth 2.0 Multiple Response Type Encoding Practices(Auth.Responses) 에 정의된 OAuth2.0 요청 매개변수를 사용합니다.

사용자 에이전트가 인증 엔드포인트에 인증 요청을 하도록 트리거하는 클라이언트의 비표준적인 예제 HTTP 302 리디렉션 응답

HTTP/1.1 302 Found
Location: https://server.example.com/authorize?
    response_type=code
    &scope=openid%20profile%20email
    &client_id=s6BhdRkqt3
    &state=af0ifjsldkj
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb

위 클라이언트의 HTTP 302 리디렉션 응답에 대한 응답으로, 사용자 에이전트가 권한 부여 서버로 보내는 요청 예제

GET /authorize?
    response_type=code
    &scope=openid%20profile%20email
    &client_id=s6BhdRkqt3
    &state=af0ifjsldkj
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb HTTP/1.1
Host: server.example.com

3-1-2-2 인증 요청 검증

권한 부여 서버는 다음과 같이 수신된 요청을 확인해야 합니다.

권한 부여 서버는 OAuth 2.0 사양에 따라 모든 OAuth 2.0 매개변수를 검증해야 합니다.
scope 매개변수가 있고 openid 범위 값을 포함 하는지 확인하십시오.(openid 범위 값이 없는 경우 요청은 여전히 유효한 OAuth 2.0 요청일 수 있지만 OpenID Connect 요청은 아닙니다.)
권한 부여 서버는 모든 필수 매개변수가 존재하고 사용이 이 사양을 준수하는지 확인해야 합니다.
sub(subject) 클레임이 ID 토큰에 대한 특정 값으로 요청되는 경우, 권한 부여 서버는 해당 sub 값으로 식별된 최종 사용자가 권한 부여 서버와의 활성 세션을 가지고 있거나 다음과 같이 인증된 경우에만 긍정적인 응답을 보내야 합니다.
인가 서버는 인가 서버와의 활성 세션이 있더라도 다른 사용자에 대한 ID 토큰 또는 액세스 토큰으로 응답하면 안 됩니다(MUST NOT). 이러한 요청은 id_token_hint 매개변수를 사용하거나 클레임 매개변수가 구현에서 지원되는 경우 섹션 5.5.1 에 설명된 대로 특정 클레임 값을 요청 하여 만들 수 있습니다.

OAuth 2.0(RFC6749)에 지정된 대로 권한 부여 서버는 인식되지 않은 요청 매개변수를 무시해야 합니다(SHOULD).
권한 부여 서버에 오류가 발생하면 섹션 3.1.2.6 에 따라 오류 응답을 반환해야 합니다

3-1-2-3 권한부여 서버의 최종사용자 인증

요청이 유효한 경우 권한 부여 서버는 사용된 요청 매개 변수 값에 따라 최종 사용자 인증을 시도하거나 최종 사용자가 인증되었는지 여부를 결정합니다. 권한 부여 서버가 최종 사용자를 인증하기 위해 사용하는 방법(예: 사용자 이름 및 암호, 세션 쿠키 등)은 이 사양의 범위를 벗어납니다. 인증 사용자 인터페이스(Authentication user interface)는 사용된 요청 매개 변수 값과 사용된 인증 방법에 따라 권한 부여 서버에 의해 표시될 수 있습니다(MAY).

권한 부여 서버는 다음과 같은 경우 최종 사용자 인증을 시도해야 합니다

최종 사용자가 아직 인증되지 않았을 때
인증 요청(Authentication Request)에 prompt 매개변수에 login값이 있을 때. 이 경우 권한 부여 서버는 최종 사용자가 이미 인증된 경우에도 최종 사용자를 재인증해야 합니다.

권한 부여 서버는 다음과 같은 경우에 최종 사용자와 상호 작용해서는 안 됩니다(MUST NOT)

인증 요청(Authentication Request)에 값이 none인 prompt매개변수가 포함되어 있을 때.
이 경우 권한 부여 서버는 최종 사용자가 아직 인증되지 않았거나 자동으로 인증될 수 없는 경우 오류를 반환해야 합니다.

최종 사용자와 상호 작용할 때 인가 서버는 OAuth 2.0 [RFC6749]의 섹션 10.12 및 10.13에 설명된 대로 교차 사이트 요청 위조(Cross-Site Request Forgery) 및 클릭재킹(Clickjacking )에 대해 적절한 조치를 취해야 합니다.

3-1-2-4 권한 부여 서버의 최종 사용자 동의/권한 획득

최종 사용자가 인증되면 인가 서버는 신뢰 당사자에게 정보를 공개하기 전에 인가 결정을 얻어야 합니다. 사용된 요청 매개변수에 의해 허용되는 경우, 이는 최종 사용자와의 대화식 대화를 통해 무엇에 동의하는지 명확히 하거나 요청 또는 기타 수단을 처리하기 위한 codintions을 통해 동의를 설정함으로(예: 이전 관리 동의) 수행한다. 섹션 2 및 5.3 은 정보 공개 메커니즘을 설명합니다.

3-1-2-5 성공적인 인증 응답

인증 응답은 RP가 보낸 Authorization Request 메시지에 대한 응답으로 OP의 Authorization Endpoint에서 반환되는 OAuth 2.0 Authorization Response 메시지입니다.

인증 코드 흐름(Authorization Code Flow)을 사용할 때 인증 응답은 OAuth 2.0 [RFC6749]의 섹션 4.1.2에 정의된 매개변수를 다른 응답 모드가 지정되지 않은 경우 application/x-www-form-urlencoded 형식을 사용하여 인증 요청(Authorization Request)에 지정된 redirect_uri에 쿼리 매개변수로 추가합니다.

다음은 이 흐름을 사용하는 비표준적인 성공적인 응답의 예입니다

HTTP/1.1 302 Found
Location: https://client.example.org/cb?
  code=SplxlOBeZQQYbYS6WxSbIA
  &state=af0ifjsldkj

인증 코드의 내용에 대한 구현 참고 사항은 섹션 15.5.1 을 참조하십시오 .

참고 : Content-Type

Content-Type은 api 연동시에 보내는 자원을 명시하기 위해 사용합니다.
Message Body에 들어가는 타입을 HTTP Header에 명시해줄 수 있는데 이때 명시해줄 수 있도록 해주는 필드가 바로 Content Type입니다.

+---------------+
| Request Line  |
+---------------+
| HTTP Header   |
+---------------+
| Empty Line    |
+---------------+
| Message Body  |
+---------------+

body의 타입정보를 표현하기 위해 헤더에 사용하는 Content Type 종류
1. Text타입: text/css, text/javascript, text/html, text/plain
2. file : multipart/form-data
3. Application 타입
  - application/json : {key: value}의 형태로 전송
  - application/x-www-urlencoded : html의 form의 기본 Content-Type으로 key=value&key=value의 형태로 전달. 보내는 데이터를 URL인코딩 후에 웹서버로 보내는 방식

3-1-2-6 인증 오류 응답

인증 오류 응답은 RP가 보낸 인증 요청 메시지에 대한 응답으로 OP의 인증 엔드포인트에서 반환된 OAuth 2.0 인증 오류 응답 메시지입니다.

최종 사용자가 요청을 거부하거나 최종 사용자 인증이 실패하면 OP(인증 서버)는 OAuth 2.0 [RFC6749] 의 섹션 4.1.2.1에 정의된 오류 응답 매개변수를 사용하여 RP(클라이언트)에 알립니다 . (RFC 6749와 관련되지 않은 HTTP 오류는 적절한 HTTP 상태 코드를 사용하여 사용자 에이전트로 반환됩니다.)

리디렉션 URI가 유효하지 않은 경우 권한 부여 서버는 클라이언트를 적절한 오류 및 상태 매개 변수와 함께 권한 부여 요청에 지정된 리디렉션 URI로 반환합니다. 다른 매개변수는 반환되지 않아야 합니다(SHOULD NOT).

오류 응답 예

HTTP/1.1 302 Found
Location: https://client.example.org/cb?
  error=invalid_request
  &error_description=
    Unsupported%20response_type%20value
  &state=af0ifjsldkj

3-1-2-7 인증 응답 검증

인증 코드 흐름을 사용할 때 클라이언트는 RFC 6749, 특히 섹션 4.1.2 및 10.12에 따라 응답을 확인해야 합니다.

3-1-3 Token Endpoint

Authorization Code Flow을 사용할 때 액세스 토큰, ID 토큰 및 선택적으로 새로 고침 토큰을 얻기 위해 RP(클라이언트)는 OAuth 2.0 [RFC6749]의 섹션 3.2에 설명된 대로 토큰 응답을 얻기 위해 토큰 끝점에 토큰 요청을 보냅니다.

토큰 끝점과의 통신은 TLS를 활용해야 합니다. TLS 사용에 대한 자세한 내용 은 섹션 16.17 을 참조하십시오 .

3-1-3-1 토큰 요청

클라이언트는 OAuth 2.0 [RFC6749] 의 섹션 4.1.3에 설명된 대로 grant_type 값 authorization_code 를 사용하여 토큰 엔드포인트에 인증 코드 형식으로 인증 부여(Authorization Grant)를 제공하여 토큰 요청을 합니다.
클라이언트가 기밀 클라이언트인 경우 섹션 9 에 설명된 대로 client_id 에 등록된 인증 방법을 사용하여 토큰 엔드포인트에 인증해야 합니다 .

클라이언트는 OAuth 2.0 [RFC6749] 의 섹션 4.1.3에 설명된 대로 섹션 13.2 에 따라 HTTP POST 메서드 및 form 직렬화를 사용하여 매개변수를 토큰 엔드포인트로 보냅니다 .

토큰 요청(Token Request) 예시

  POST /token HTTP/1.1
  Host: server.example.com
  Content-Type: application/x-www-form-urlencoded
  Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW

  grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
      &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb

3-1-3-2 토큰 요청 검증

권한 부여 서버는 다음과 같이 토큰 요청을 확인해야 합니다.

클라이언트 자격 증명이 발급되었거나 섹션 9 에 따라 다른 클라이언트 인증 방법을 사용하는 경우 클라이언트를 인증합니다 .
인증된 클라이언트에게 인증 코드(Authorization Code)가 발급되었는지 확인하십시오.
인증 코드가 유효한지 확인하십시오.
가능하면 인증 코드가 이전에 사용된 적이 없는지 확인하십시오.
redirect_uri 매개변수 값이 초기 승인 요청에 포함된 redirect_uri 매개변수 값과 동일한지 확인하십시오 . 등록된 redirect_uri 값이 하나만 있을 때 redirect_uri 매개변수 값이 없으면 권한 부여 서버는 오류를 반환하거나(클라이언트가 매개변수를 포함해야 하므로) 오류 없이 진행할 수 있습니다(OAuth 2.0에서는 이 경우 매개변수 생략을 허용하므로).
사용된 인증 코드가 OpenID Connect 인증 요청에 대한 응답으로 발급되었는지 확인합니다(토큰 끝점에서 ID 토큰이 반환되도록).

3-1-3-3 성공적인 토큰 응답

클라이언트로부터 유효하고 인증된 토큰 요청을 수신하고 검증한 후 인증 서버는 ID 토큰과 액세스 토큰을 포함하는 성공적인 응답을 반환합니다. 성공적인 응답의 매개변수는 OAuth 2.0 [RFC6749]의 섹션 4.1.4에 정의되어 있습니다. 응답은 application/json 미디어 유형을 사용합니다.

OAuth 2.0 token_type 응답 매개변수 값은 다른 토큰 유형이 클라이언트와 협상되지 않는 한 OAuth 2.0 Bearer Token Usage [RFC6750]에 지정된 Bearer 여야 합니다. 서버는 전달자 토큰 유형을 지원해야 합니다(SHOULD). 다른 토큰 유형의 사용은 이 사양의 범위를 벗어납니다.

OAuth 2.0에서 지정한 응답 매개변수 외에도 다음 매개변수가 응답에 포함되어야 합니다.

id_token
-인증된 세션과 연결된 ID 토큰 값입니다.

토큰, 비밀 또는 기타 민감한 정보를 포함하는 모든 토큰 응답에는 다음 HTTP 응답 헤더 필드 및 값이 포함되어야 합니다.

Header Name	Header Value
Cache-Control	no-store
Pragma	no-cache

다음은 성공적인 토큰 응답의 비표준적인 예입니다OAuth 2.0 [RFC6749]에 지정된 대로 클라이언트는 인식할 수 없는 응답 매개변수를 무시해야 합니다(SHOULD).

  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"
  }

3-1-3-4 토큰 오류 응답

토큰 요청이 유효하지 않거나 승인되지 않은 경우 권한 부여 서버는 오류 응답을 구성합니다. 토큰 오류 응답의 매개변수는 OAuth 2.0 [RFC6749]의 섹션 5.2에 정의되어 있습니다. HTTP 응답 본문은 HTTP 응답 코드가 400인 application/json 미디어 유형을 사용합니다.

다음은 토큰 오류 응답의 예입니다.

```
HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache

{
"error": "invalid_request"
}
```

3-1-3-5 토큰 응답 검증

클라이언트는 다음과 같이 토큰 응답을 검증해야 합니다.

RFC 6749, 특히 섹션 5.1 및 10.12의 유효성 검사 규칙을 따릅니다.
섹션 3.1.3.7 의 ID 토큰 유효성 검사 규칙을 따릅니다 .
섹션 3.1.3.8 의 액세스 토큰 유효성 검사 규칙을 따릅니다 .

3-1-3-6 ID Token

D 토큰의 내용은 2절에 설명되어 있습니다. 인증 코드 흐름을 사용하는 경우 다음 ID 토큰 클레임에 대한 이러한 추가 요구 사항이 적용됩니다.

at_hash
- OPTIONAL. 액세스 토큰 해시 값. 그 값은 access_token 값의 ASCII 표현 옥텟의 해시 중 가장 왼쪽 절반의 base64url 인코딩입니다. 여기서 사용된 해시 알고리즘 은 ID 토큰의 JOSE 헤더의 alg 헤더 매개변수에 사용된 해시 알고리즘입니다. 예를 들어 alg 가 RS256 이면 access_token 값을 SHA-256으로 해시한 다음 맨 왼쪽 128비트를 가져와서 base64url로 인코딩합니다. at_hash 값 은 대소문자를 구분하는 문자열입니다.

3-1-3-7 ID 토큰 유효성 검사

클라이언트는 다음과 같은 방식으로 토큰 응답에서 ID 토큰을 검증해야 합니다.

ID 토큰이 암호화된 경우, OP가 ID 토큰을 암호화하는 데 사용할 Registration 과정 중에 클라이언트가 지정한 키와 알고리즘을 사용하여 암호를 해독합니다. 등록 시 OP와 암호화가 협상되었고 ID 토큰이 암호화되지 않은 경우 RP는 이를 거부해야 합니다.
OpenID 공급자에 대한 발급자 식별자(일반적으로 Discovery 중에 얻음)는 iss(발급자) 클레임의 값과 정확히 일치해야 합니다.
클라이언트는 aud 클레임이, 대상으로 iss클레임에 의해 식별된 발급자(Issuer)에 등록된 client_id 값을 포함하는지 확인해야 합니다 . aud클레임에는 둘 이상의 요소가 있는 배열이 포함될 수 있습니다(MAY) . ID 토큰이 클라이언트를 유효한 청중(audiences)으로 나열하지 않거나 클라이언트가 신뢰하지 않는 추가 청중을 포함하는 경우 ID 토큰은 거부되어야 합니다.
ID 토큰에 여러 대상(audiences)이 포함된 경우 클라이언트는 azp 클레임이 있는지 확인해야 합니다(SHOULD).
azp(authorized party) 클레임이 있는 경우 클라이언트는 해당 client_id 가 클레임 값인지 확인해야 합니다(SHOULD) .
ID 토큰이 클라이언트와 토큰 끝점(이 흐름에 있음) 간의 직접 통신을 통해 수신된 경우 TLS 서버 유효성 검사를 사용하여 토큰 서명을 확인하는 대신 발급자를 확인할 수 있습니다(MAY). 클라이언트는 JWT alg 헤더 매개변수 에 지정된 알고리즘을 사용하여 JWS(JSON Web Signature) 에 따라 다른 모든 ID 토큰의 서명을 확인해야 합니다. 클라이언트는 발행자가 제공한 키를 사용해야 합니다.
alg값은 RS256의 기본값이거나 등록과정 중에 클라이언트가 id_token_signed_response_alg 매개변수에 작성한 알고리즘이여야 한다.( SHOULD )
JWT alg 헤더 매개변수가 HS256 , HS384 또는 HS512 와 같은 MAC 기반 알고리즘을 사용하는 경우 aud 클레임 에 포함된 client_id 에 해당하는 client_secret 의 UTF-8 표현의 옥텟이 유효성을 검사하는 키로 사용됩니다. 서명. MAC 기반 알고리즘의 경우 aud 가 다중 값이거나 aud 값과 다른 azp 값이 있는 경우 동작이 지정되지 않습니다 .
현재 시간은 exp 클레임 이 나타내는 시간 이전이어야 합니다 .
iat 클레임을 사용하여 현재 시간에서 너무 멀리 발행된 토큰을 거부하여, 공격을 방지하기 위해 nonce를 저장해야 하는 시간을 제한할 수 있습니다. 허용 범위는 클라이언트에 따라 다릅니다.
인증 요청에서 nonce 값이 전송된 경우 nonce Claim이 존재해야 하며 해당 값이 인증 요청에서 전송된 값과 동일한지 확인해야 합니다. 클라이언트는 replay 공격에 대한 nonce 값을 확인해야 합니다(SHOULD). replay 공격을 탐지하는 정확한 방법은 클라이언트별로 다릅니다.
acr 클레임이 요청된 경우 클라이언트는 클레임 값이 적절한지 확인해야 합니다. acr 클레임 값의 의미와 처리는 이 사양의 범위를 벗어납니다.
이 클레임에 대한 특정 요청을 통하거나 또는 max_age 매개변수를 사용하여 auth_time 클레임이 요청된 경우, 클라이언트는 auth_time 클레임 값을 확인하고 마지막 최종 사용자 인증 이후 너무 많은 시간이 경과했다고 판단되면 재인증을 요청 해야 합니다(SHOULD).

3-1-3-8 엑세스 토큰 유효성 검사

권한 부여 코드 흐름을 사용할 때 ID 토큰에 at_hash 청구가 포함되어 있으면, 클라이언트는 3.2.2.9절 에 정의된 대로 암시적 흐름과 동일한 방식으로 액세스 토큰을 검증하는 데 사용할 수 있다. 그러나 토큰 끝점에서 반환된 ID 토큰 및 액세스 토큰을 사용합니다

참고문서

https://openid.net/specs/openid-connect-core-1_0.html

저작자표시 비영리 변경금지

개발 여정