Table of Contents
このドキュメントでは、RFC6749 と OpenID Connect の違いに着目しつつ、認可エンドポイント（authorization endpoint） について説明します。RFC 6749 等の仕様に詳しい場合は、読み飛ばしていただいて構いません。
認可エンドポイントのパス（Path）について、RFC 6947 で指定されていることは、「エンドポイント URI はフラグメントを含んではならない（The endpoint URI MUST NOT include a fragment component）」ということだけです。上記さえ守られている限り、如何なる名前も使えます。例えば、/auth/authorization（完全なURLとして書くと、https://example.com/auth/authorization）は、認可エンドポイントの URI として適切です。
RFC 6749 では、認可エンドポイントにおいて TLS（Transport Layer Security）を使うことが要求されています。
RFC 6749, 3.1. Authorization Endpoint に従うと、認可エンドポイントは、GETをサポートすることは必須ですが、POSTのサポートに関しては任意です。しかし、OpenID Connect Core 1.0, 3.1.2.1. Authentication Request では、認可エンドポイントは、POSTをサポートすることが要求されています。また、POSTを使う場合、パラメーターを application/x-www-form-urlencoded の形でフォーマットすることが必須です。
Table. HTTP Methods Of The Authorization Endpoint
| HTTP method | RFC 6749 | OpenID Connect |
|---|---|---|
| GET | MUST | MUST |
| POST | MAY | MUST |
RFC 6749 では、1.3. Authorization Grant において４つの grant type が定義されています。grant type とは、認可サーバーがアクセストークンを発行するフローの種類です。４つのうち、Authorization Code Grant（認可コードフロー、とも言う）と Implicit Grant（インプリシットフロー、とも言う）の２つに関しては、認可エンドポイントを利用します。両フローとも、認可エンドポイントで受け取るリクエストパラメーター名は同じです。
Table. RFC 6749 にて定義されている認可エンドポイントへのリクエストパラメーター
| パラメーター名 | 条件 | 詳細 |
|---|---|---|
response_type |
REQUIRED | code for Authorization Code Grant and token for Implicit Grant. |
client_id |
REQUIRED | The client ID of the client application which is making the authorization request. A client ID is an opaque number or string issued by a service. |
redirect_uri |
OPTIONAL | The URL to which the client application requests the result of the authorization request to be reported. If the client application has registered multiple redirect URIs or has not registered any redirect URI (this is allowed when the client type of the client application is “confidential”), this request parameter is REQUIRED. |
scope |
OPTIONAL | A space-delimited list of scopes (= permissions) that the client application requires. Valid scope values are defined by a service. Some implementations of OAuth 2.0 (e.g. Facebook) require a comma-delimited list, but it is just a violation against the specification. |
state |
RECOMMENDED | An opaque value that the client application may use. If this request parameter is contained in the authorization request, it is passed to the redirect URI. |
OpenID Connect では、さらにパラメーターが追加されています。その多くは、OpenID Connect Core 1.0, 3.1.2.1. Authentication Request に記載されています。次に示す表は、RFC 6749、OpenID Connect およびその他の関連仕様で定義さているリクエストパラメーターを一覧にしたものです。
Table. OAuth/OpenID Connect で定義されている認可エンドポイントへのリクエストパラメーター
| パラメーター名 | 条件 | 詳細 |
|---|---|---|
response_type |
REQUIRED | In RFC 6749, the valid values of this request parameter are just two, namely, code and token. However, OpenID Connect has extended them to combinations of code, id_token and token, or none. As a result, the valid values are as follows.
|
client_id |
REQUIRED | The same requirement as RFC 6749. |
redirect_uri |
REQUIRED | In RFC 6749, this request parameter is OPTIONAL. But in OpenID Connect, it is REQUIRED. |
scope |
REQUIRED | In RFC 6749, this request parameter is OPTIONAL. But in OpenID Connect, it is REQUIRED and must contain openid. |
state |
RECOMMENDED | The same requirement as RFC 6749. |
response_mode |
OPTIONAL | A new request parameter defined in OAuth 2.0 Multiple Response Type Encoding Practices. This request parameter specifies how the result of the authorization request should be formatted. |
nonce |
OPTIONAL | A new request parameter. An opaque string value that will be embedded in an ID token. If response_type request parameter contains id_token (meaning that an ID token is issued using Implicit Flow), nonce is REQUIRED. |
display |
OPTIONAL | A new request parameter to specify how the user interface should be displayed to the end-user. |
prompt |
OPTIONAL | A new request parameter to specify whether the service should prompt the end-user for re-authentication and consent. |
max_age |
OPTIONAL | A new request parameter to specify the maximum authentication age. |
ui_locales |
OPTIONAL | A new request parameter to specify preferred languages and scripts for the user interface. |
id_token_hint |
OPTIONAL | A new request parameter to specify the ID token previously issued by the service. |
login_hint |
OPTIONAL | A new request parameter to specify a hint about the login identifier that the end-user may use. |
acr_values |
OPTIONAL | A new request parameter to specify ACRs (Authentication Context Class References) one of which the client application requests to be satisfied. |
claims_locales |
OPTIONAL | A new request parameter to specify the end-user’s preferred locales for ID token claims. This request parameter is defined in OpenID Connect Core 1.0, 5.2. Claims Languages and Scripts. |
claims |
OPTIONAL | A new request parameter to specify specific claims that the client application requests to be embedded in the ID token returned. This request parameter is defined in OpenID Connect Core 1.0, 5.5. Requesting Claims using the “claims” Request Parameter. |
request |
OPTIONAL | A new request parameter to specify a request object, which is a JWT packing other request parameters and being signed and optionally encrypted. This request parameter is defined in OpenID Connect Core 1.0, 6. Passing Request Parameters as JWTs. |
request_uri |
OPTIONAL | A new request parameter to specify the location of a request object. This request parameter is defined in OpenID Connect Core 1.0, 6. Passing Request Parameters as JWTs. |
registration |
OPTIONAL | A new request parameter to provide additional registration information about the client application itself. This request parameter is defined in OpenID Connect Core 1.0, 7.2.1. Providing Information with the “registration” Request Parameter. |
code_challenge |
CONDITIONALLY REQUIRED | A new request parameter to specify a code challenge as a countermeasure against the code interception attack. This request parameter is defined in RFC 7636 (Proof Key for Code Exchange by OAuth Public Clients). Authorization server implementations may always require this parameter for authorization requests using Authorization Code Flow. See “Proof Key for Code Exchange (RFC 7636)” for details. |
code_challenge_method |
OPTIONAL | A new request parameter to tell the method used to generate a code challenge. This request parameter is defined in RFC 7636 (Proof Key for Code Exchange by OAuth Public Clients). Valid values are plain (default) and S256. See “Proof Key for Code Exchange (RFC 7636)” for details. |
RFC 6749 に従うと、認可リクエストが成功した場合、認可エンドポイントは、認可コード（authorization code または アクセストークン（access token） を発行することになります。
上記に加え、OpenID Connect ではさらにオブジェクトが追加され、ID トークン（ID token） を発行することが可能となりました。OpenID Connect は OAuth 2.0 を拡張する形で作られた仕様であり、主な目的は、エンドユーザーが認証されたという情報を ID トークンの形で利用できるようにすることです。
認可エンドポイントから返されるオブジェクトをまとめると下記のようになります。
Table. 認可エンドポイントから返されるオブジェクト一覧
| オブジェクト | 説明 |
|---|---|
| 認可コード | 無意味な文字列であり、トークンエンドポイントにてアクセストークンと交換される、短命のチケットのようなもの |
| アクセストークン | 無意味な文字列であり、誰（エンドユーザー）が何の権限（scope）をどのクライアントに与えたのかを示すもの（注：Client Credentials Flow を用いて発行されたアクセストークンの場合、「誰が」に関する情報は含まれない） |
| ID トークン | エンドユーザーに関する情報を含む JWT |
OpenID Connect が定義される以前は、認可エンドポイントが返却するオブジェクトは、認可コードまたはアクセストークンのいずれかでした。OpenID Connect 以降、上記の３つすべてを返す場合もあり、それは認可リクエスト中の response_type パラメーターの値で決まります。response_type と認可エンドポイントで返されるオブジェクトの関係を以下に示します。
Table. response_type と認可エンドポイントで返されるオブジェクトの関係
| response_type | Returned Objects | ||
| Authorization Code | Access Token | ID Token | |
none |
|||
code |
|||
token |
|||
id_token |
|||
code token |
|||
code id_token |
|||
id_token token |
|||
code id_token token |
|||
認可エンドポイントからのレスポンスの中には、認可コード、アクセストークンおよび ID トークンが、それぞれ、 code、access_token、id_tokenといったパラメーターキーで含まれます。例えば、レスポンス中に code=SplxlOBe とある場合、認可コードは SplxlOBe となります。
認可エンドポイントからの認可レスポンス中に含まれる可能性のあるパラメーターは下記のとおりです。
Table. Response Parameters From The Authorization Endpoint
| No. | Name | Description |
| 1 | code |
An authorization code issued to the client application. This is
contained in a successful response when
|
| 2 | access_token |
An access token issued to the client application. This is
contained in a successful response when
|
| 3 | id_token |
An ID token issued to the client application. This is
contained in a successful response when
|
| 4 | state |
When an authorization request contains |
| 5 | error |
An error code. This is contained in a response when an error occurred. |
| 6 | error_description |
The short description of the error which happened. This may be contained in a response when an error occurred. |
| 7 | error_uri |
The URI where the detailed description of the error can be found. This may be contained in a response when an error occurred. |
| 8 | token_type |
The token type of the access token. This is contained in a
successful response when |
| 9 | expires_in |
The lifetime in seconds of the access token. This may be
contained in a successful response when
|
| 10 | scope |
A space-delimited scope list of the access token. This may be
contained in a successful response when
|
RFC 6749 に従うと、認可コードフローまたはインプリシットフローの場合、認可エンドポイントからの正常なレスポンスの HTTP ステータスは、"302 Found“であり、これにより、ユーザーエージェント（エンドユーザーがもちいている web ブラウザ）は別の場所へリダイレクトされます。OAuth 2.0 では、このリダイレクト先の場所を、リダイレクト URI と表現します。
リダイレクトURIの一部として、認可サーバーからのレスポンスパラメーターがクライアントアプリに手渡されます。例えば、
https://client.example.org/callbackap8uacb2の場合、認可エンドポイントからクライアントアプリへのレスポンスは下記のようになります。
HTTP/1.1 302 Found
Location: https://client.example.org/callback?code=ap8uacb2
Cache-Control: no-store
Pragma: no-cache
別の例を見てみましょう。例えば、
pqb8u3tの場合、レスポンスは下記のとおりになります。
HTTP/1.1 302 Found
Location: https://client.example.org/callback#access_token=pqb8u3t
&token_type=Bearer
&expires_in=3600
Cache-Control: no-store
Pragma: no-cache
すでにお気付きかもしれませんが、認可コードフローの場合、パラメーターは query として渡され、インプリシットフローの場合は、 fragment として渡されます。この差は、RFC6749 の要求事項からくるものです。
Table. Relationship Between response_type And Response Parameter's Location
| response_type | HTTP status | Response Parameters’ Location |
|---|---|---|
| code | 302 Found | Embedded in the query component of the redirect URI in the Location header. |
| token | 302 Found | Embedded in the fragment component of the redirect URI in the Location header. |
ただ、OpenID Connect、より具体的には、OAuth 2.0 Form Post Response Mode によって、さらに複雑になります。上記の仕様により、レスポンスフォーマットをコントロールする仕組みが導入され、"302 Found“に加え、 “200 OK“も利用可能となりました。“200 OK"は、認可リクエスト中に response_mode=form_post が含まれている場合に発生します。下記に仕様からの抜粋を示します。
HTTP/1.1 200 OK
Content-Type: text/html;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
<html>
<head><title>Submit This Form</title></head>
<body onload="javascript:document.forms[0].submit()">
<form method="post" action="https://client.example.org/callback">
<input type="hidden" name="state" value="DcP7csa3hMlvybERqcieLHrRzKBra"/>
<input type="hidden" name="id_token"
value="eyJhbGciOiJSUzI1NiIsImtpZCI6IjEifQ.eyJzdWIiOiJqb2huIiw
iYXVkIjoiZmZzMiIsImp0aSI6ImhwQUI3RDBNbEo0c2YzVFR2cllxUkIiLC
Jpc3MiOiJodHRwczpcL1wvbG9jYWxob3N0OjkwMzEiLCJpYXQiOjEzNjM5M
DMxMTMsImV4cCI6MTM2MzkwMzcxMywibm9uY2UiOiIyVDFBZ2FlUlRHVE1B
SnllRE1OOUlKYmdpVUciLCJhY3IiOiJ1cm46b2FzaXM6bmFtZXM6dGM6U0F
NTDoyLjA6YWM6Y2xhc3NlczpQYXNzd29yZCIsImF1dGhfdGltZSI6MTM2Mz
kwMDg5NH0.c9emvFayy-YJnO0kxUNQqeAoYu7sjlyulRSNrru1ySZs2qwqq
wwq-Qk7LFd3iGYeUWrfjZkmyXeKKs_OtZ2tI2QQqJpcfrpAuiNuEHII-_fk
IufbGNT_rfHUcY3tGGKxcvZO9uvgKgX9Vs1v04UaCOUfxRjSVlumE6fWGcq
XVEKhtPadj1elk3r4zkoNt9vjUQt9NGdm1OvaZ2ONprCErBbXf1eJb4NW_h
nrQ5IKXuNsQ1g9ccT5DMtZSwgDFwsHMDWMPFGax5Lw6ogjwJ4AQDrhzNCFc
0uVAwBBb772-86HpAkGWAKOK-wTC6ErRTcESRdNRe0iKb47XRXaoz5acA"/>
</form>
</body>
</html>
上記の HTML 上では、リダイレクト URIは form タグの中の action として、レスポンスパラメーターは隠しパラメーターとして設定されています。各隠しパラメーターの名前が、state 及び id_token となっていることが確認できます。
ユーザーエージェントにて上記 HTML が読み込まれた後、onload で定義されている JavaScript が実行されます。結果、指定の リダイレクト URI へリダイレクトされます。
下記の表は、response_type と response_mode の組み合わせに対する、HTTPステータスとレスポンスパラメーターが含まれている場所を示しています。
Table. Relationship Between response_type/response_mode Combinations And HTTP Status/Response Parameters' Location
| response_type | response_mode | |||
| (default) | query | fragment | form_post | |
| 302 Found | 200 OK | |||
none |
Query component | Query component | Fragment component | Hidden parameters |
code |
||||
token |
Fragment component | NOT ALLOWED | Fragment component | Hidden parameters |
id_token |
||||
code token |
||||
code id_token |
||||
id_token token |
||||
code id_token token |
||||
認可リクエストを処理している間にエラーが発生した場合、サービスはクライアントアプリにエラーレスポンスを返します。エラーが発生する時点で、エラーを報告すべきリダイレクト URI が確定している場合、エラーはリダイレクト URI に送付されます。その際、レスポンス中に必ず error レスポンスパラメーターが含まれます。上記に加え、error_description 及び error_uri が含まれる場合もあります。例えば、下記のようなレスポンスがクライアントアプリに返されます。
HTTP/1.1 302 Found
Location: https://client.example.org/callback?error=access_denied
&error_description=The%20end-user%20denied%20the%20authorization%20request.
Cache-Control: no-store
Pragma: no-cache
認可エンドポイントからの返される error レスポンスパラメーターが取りうる値は、RFC 6749 の 4.1.2.1. Error Response (認可コードフロー) および 4.2.2.1. Error Response (インプリシットフロー) にて定義されています。また、OpenID Connect Core 1.0 に関しては、3.1.2.6. Authentication Error Response にて定義されています。
下記に、エラーコードの一覧を示します。
Table. Values of error from the Authorization Endpoint
| Value | RFC 6749 | OpenID Connect |
|---|---|---|
| access_denied | ||
| account_selection_required | ||
| consent_required | ||
| interaction_required | ||
| invalid_request | ||
| invalid_request_object | ||
| invalid_request_uri | ||
| invalid_scope | ||
| login_required | ||
| registration_not_supported | ||
| request_not_supported | ||
| request_uri_not_supported | ||
| server_error | ||
| temporarily_unavailable | ||
| unauthorized_client | ||
| unsupported_response_type |
リダイレクト URI が特定される前にエラーが発生する可能性があります。例えば、提示されたクライアント ID が無効で、指定されたリダイレクト URI が登録済みかどうか確かめることができないとき、3. エラーレスポンスに示した方法でエラーを伝えることはできません。
RFC 6749, 3.1.2.4. Invalid Endpoint では、下記のように言及されています。
If an authorization request fails validation due to a missing, invalid, or mismatching redirection URI, the authorization server SHOULD inform the resource owner of the error and MUST NOT automatically redirect the user-agent to the invalid redirection URI.
しかしながら、リソースオーナー（エンドユーザー）にエラーを通知する方法は明記されていません。考えられる方法としては、以下の選択肢が考えられます。
| HTTP Status | Content-Type | Comment |
|---|---|---|
| 400 Bad Request | text/html |
The error is described in HTML format and shown in the user agent. This is friendly to end-users and testers. |
| 400 Bad Request | application/json |
The error is described in JSON format in the same way as the token endpoint does (RFC 6749, 5.2. Error Response). This is friendly to developers of client applications. |
OpenID Connect において追加されたユースケース、具体的には、ユーザーとの連携がなされない prompt=none の場合を想定すると、application/json の方が良い選択肢かと思います。
認可エンドポイントの主たるタスクは、クライアントアプリに対して、エンドユーザーの認可を与えることです。通常、このプロセスは下記の特徴を持つ HTML ページを表示することで達成されます。
下記に示したフォームは、認可エンドポイントが生成する認可画面の採用構成を示した例です。
OAuth は**認可（authorization）**のためのフレームワークであり、**認証（authentication）**のためのフレームワークではありません。RFC 6749, 3.1. Authorization Endpoint にて言及されているように、認可サーバーがリソースオーナーを認証する方法については OAuth のスコープ外です。クライアントクレデンシャルグラントを除き、アクセストークンをリソースオーナーに紐づけるためにも、エンドユーザーは認可エンドポイントにおいて認証される必要があります。
RFC 6749 にて言及されていないこともあり、エンドユーザーの認証方式については実装者が自由に設計できます。しかし、OpenID Connect において、エンドユーザーの認証をコントロールする機構が導入されています。下記に、それらについて説明します。
prompt リクエストパラメーター任意のパラメーターである prompt リクエストパラメーターは、「認可サーバーがエンドユーザーに再認証と同意を求めるかどうか」を指定します（OpenID Connect Core 1.0, 3.1.2.1. Authentication Request)。
その値は、login、consent、select_account および none の、スペース区切りの組み合わせになります。他の値を用いることはできません。各値は、それぞれ以下のような意味を持ちます。
| Value | Description |
|---|---|
login |
When prompt contains login, the end-user must be authenticated even when he/she has already logged in. |
consent |
When prompt contains consent, consent must be obtained from the end-user even when the authorization endpoint implementation knows that the consent was obtained in the past. |
select_account |
When prompt contains select_account, the authorization endpoint implementation should prompt the end-user to select a user account. |
none |
When prompt is none, the authorization endpoint implementation must process the authorization request without displaying any UI (= without user interaction). |
login、consent、select_account の３つの組み合わせを満足するためのもっとも単純な実装は、ログイン ID とパスワードを入力するフォームを表示することです。
認証コンテキストクラスリファレンス（Authentication Context Class Reference、ACR） は、認証方式のコンテキスト、レベルおよびその他の属性を示す文字列です。例えば、urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport（Authentication Context for the OASIS Security Assertion Markup Language (SAML) V2.0. からの抜粋）は、保護されたセッション内でパスワードを提示する認証方式を意味します。
OpenID Connect Core 1.0 では、「０」以外の具体的な ACR の値について言及がありません。ただ、ACR の値を用いるパーティー（例えば認可サーバーやクライアントアプリ）は**『用いられている値の意味に同意する必要がある』** とだけ述べられています（OpenID Connect Core 1.0, 2. ID Token, acr）。
acr_values リクエストパラメーターacr_values リクエストパラメーター (OpenID Connect Core 1.0, 3.1.2.1. Authentication Request, acr_values) は、ACR のリストを指定するためのパラメーターです。認可リクエスト中にこのパラメーターがある場合、認可エンドポイントの実装は、エンドユーザーの認証に関して、指定されたリストの中の一つを満足する必要があります。
claims リクエストパラメーター中の acr クレームACR のリストを指定する方法は他にもあります。claim リクエストパラメーターの値の中に acr クレームを含むことによっても指定でします。下記の JSON は、claim リクエストパラメーターの値の例です (OpenID Connect Core 1.0, 5.5. Requesting Claims using the “claims” Request Parameter からの抜粋です)。
{
"userinfo":
{
"given_name": {"essential": true},
"nickname": null,
"email": {"essential": true},
"email_verified": {"essential": true},
"picture": null,
"http://example.info/claims/groups": null
},
"id_token":
{
"auth_time": {"essential": true},
"acr": {"values": ["urn:mace:incommon:iap:silver"] }
}
}
claim リクエストパラメーターによって指定される場合、ACR の要求は、“essential” のみとなります。
{
"id_token":
{
"acr":
{
"essential": true,
"values": ["urn:mace:incommon:iap:silver"]
}
}
}
もし、acr クレームが必須の場合、値に指定されている ACR のリストのうちのどれかを満たす必要があります。もし、どれも対応できない場合、認可エンドポイントは、クライアントアプリにエラーメッセージを返す必要があります。詳細は、 OpenID Connect Core 1.0, 5.5.1.1. Requesting the “acr” Claim をご参照ください。
acr クレームID トークンは、acr クレームを含むことができます。詳細は、 “OpenID Connect Core 1.0, 2. ID Token, acr” をご参照ください。
“OpenID Connect Discovery 1.0, 3. OpenID Provider Metadata” では、OpenID Provider の属性をリストにしています。その中にある、acr_values_supported メタデータは、OpenID Provider によってサポートされている ACRのリストを指定します。
Authleteでは、サービスの supportedAcrs がこれに該当します。
“OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata” はクライアントアプリの属性をリスト化しています。その中にある、acr_values_supported メタデータは、ACR 値を明示しないクライアントアプリからの認可リクエストが来た際に、使われるべきデフォルトの ACR 値を指定しています。
Authlete では、クライアントの defaultAcrs がこれに該当します。
最大認証期間 (Maximum Authentication Age) は、「最大で許容される、最後にエンドユーザーが認証されてからの経過時間」を秒で示したものです (OpenID Connect Core 1.0, 3.1.2.1. Authentication Request, max_age)。もし、経過時間が最大認証期間より長い場合、エンドユーザーはログインしていたとしても、再度認証が必要となります。
max_age リクエストパラメーター認可リクエストの中に、max_age というリクエストパラメーターを含めることで、最大認証期間を指定することができます。
“OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata” にて示されている default_max_age という属性値は、クライアントアプリからの認可リクエスト中に max_age が指定されていない場合に使われます。
Authlete では、クライアントの defaultMaxAge がこれに該当します。
sub クレームクライアントアプリは、sub クレームを使い、認可されたいサブジェクトを認可リクエストで指定することができます。以下に、sub クレームとその値を含む claims リクエストパラメーターの値の例を示します。
{
"id_token":
{
"sub": {"value": "248289761001"}
}
}
認可リクエストがサブジェクトを指定している場合、エンドユーザーの認証はそのサブジェクトに対して行われなければなりません。この条件が満たされない場合、認可サーバーはエラーレスポンスを返す必要があります。詳細は、 OpenID Connect Core 1.0, 3.1.2.2. Authentication Request Validation をご参照ください。
login_hint リクエストパラメータークライアントアプリは、認可エンドポイントに対して、ログイン ID を特定するためのヒント（例えばメールアドレスなど）を、login_hint を使って付与できます。
id_token_hint Request Parameterクライアントアプリは、過去に発行された ID トークンの値を id_token_hint というパラメーターの値として設定し、認可リクエストを送ることができます。ID トークンで示されているエンドユーザーと、すでに認証済みのエンドユーザーが同一ではない場合、認可サーバーはエラーレスポンスを返す必要があります。
OpenID Connect では、認可エンドポイントにおいて、エンドユーザーとのインタラクションを伴わずに動作するための手段が導入されています。クライアントアプリは、認可リクエスト中に prompt=none というパラメーターを含めることができます。下記の条件がすべて満たされている場合のみ、prompt=none が含まれた認可リクエストは正しく処理されます。
max_age または default_max_ageリクエストパラメーターによって、最大認証期間が指定されている場合、最後に認証してからの経過時間が最大認証期間を超えていない。claim リクエストパラメーターの値中の sub クレームによってサブジェクトが指定されている場合、エンドユーザ－のログイン ID がサブジェクトに一致している。claim リクエストパラメーターの値中のacr クレームが essential の場合、用いられる認証方式は、acr クレームによって指定されている方法のうちのどれかでなければならない。claims が要求されている場合、それらへの同意が事前に取られていなければならない（同意の取り方については、OpenID Connect のスコープ外）。