Skip to main content

​
RFC 9470 OAuth 2.0 Step Up Authentication Challenge Protocol

  1. Home
  2. RFC 9470 OAuth 2.0 Step Up Authentication Challenge Protocol

​
Overview

RFC 9470: OAuth 2.0 Step Up Authentication Challenge Protocol “introduces a mechanism for a resource server to signal to a client that the authentication event associated with the access token of the current request doesn’t meet its authentication requirements and specify how to meet them.” (excerpt from “Abstract”) As the first step, a client application (a.k.a. relying party) accesses a protected resource endpoint with an access token. The implementation of the endpoint extracts the access token from the request. Next, the implementation of the endpoint extracts information about user authentication (which the authorization server performed during the course of issuing the access token) from the access token. Then, the implementation of the endpoint checks whether the information about user authentication satisfies authentication requirements that the endpoint imposes. If the requirements are not satisfied, the implementation of the endpoint returns an error response to the client application with information about the authentication requirements. The diagram below illustrates the flow from making a request with an access token to returning an error response with authentication requirements. After receiving an error response with authentication requirements, the client application will make an authorization request again. This time, the client application needs to ask the authorization server to issue an access token that satisfies the authentication requirements.

​
Authentication Requirements

The OAuth 2.0 Step Up Authentication Challenge Protocol specification presumes two types of authentication requirements. One is authentication context class reference (a.k.a. ACR) of user authentication. The other is maximum authentication age (a.k.a. max age) of user authentication.

​
Authentication Context Class Reference (ACR)

User authentication is performed somewhere during an authorization flow. OAuth 2.0 and OpenID Connect do not define details about how to authenticate users, but client applications can specify criteria of user authentication by including a list of ACRs in an authorization request. The authorization server tries to perform user authentication that satisfies at least one of the specified ACRs. However, no error is reported even if the authorization server cannot perform such user authentication unless the acr claim is requested as “essential” (described later).

​
The acr_values Request Parameter

There are three ways to specify a list of ACRs. The first way is to use the acr_values request parameter. The parameter is defined in Section 3.1.2.1 of OpenID Connect Core 1.0 as follows.
  • acr_values: OPTIONAL. Requested Authentication Context Class Reference values. Space-separated string that specifies the acr values that the Authorization Server is being requested to use for processing this Authentication Request, with the values appearing in order of preference. The Authentication Context Class satisfied by the authentication performed is returned as the acr Claim Value, as specified in Section 2. The acr Claim is requested as a Voluntary Claim by this parameter. The value of the acr_values request parameter is a space-separated list of ACRs. It appears in an authorization request like the following. https://as.example.com/authorize?acr_values=acr1+acr2+acr3&…

    ​
    The claims Request Parameter

    The second way to specify a list of ACRs is to use the claims request parameter. The parameter is defined in Section 5.5 of OpenID Connect Core 1.0. The parameter takes a JSON object as a value and the syntax of the JSON is complex. The following JSON is an example value of the claims request parameter excerpted from OpenID Connect Core 1.0. 
    ,
"nickname": null,
"email": ,
"email_verified": ,
"picture": null,
"http://example.info/claims/groups": null
\`},
"id_token":
,
"acr":
}
}
```This example specifies a list of ACRs that has just one element, `urn:mace:incommon:iap:silver`. When an authorization request includes this JSON as the value of the `claims` request parameter, the authorization server tries to perform user authentication that satisfies criteria of `urn:mace:incommon:iap:silver`.
To make the authorization server return an error when none of the specified ACRs can be satisfied, the client application must request the `acr` as an essential claim. By adding `"essential":true` in the JSON object that follows a claim name, the client application can request the claim as essential. In the example below, the `auth_time` claim and the `acr` claim are requested as essential.
```json
,
"acr":
}
}
    The acr_values request parameter cannot request the acr claim as essential.

    ​
    The default_acr_values Client Metadata

    The last way is to use the default_acr_values client metadata. The metadata is defined in Section 2 of OpenID Connect Dynamic Client Registration 1.0 as follows.
  • default_acr_values: OPTIONAL. Default requested Authentication Context Class Reference values. Array of strings that specifies the default acr values that the OP is being requested to use for processing requests from this Client, with the values appearing in order of preference. The Authentication Context Class satisfied by the authentication performed is returned as the acr Claim Value in the issued ID Token. The acr Claim is requested as a Voluntary Claim by this parameter. The acr_values_supported discovery element contains a list of the supported acr values supported by this server. Values specified in the acr_values request parameter or an individual acr Claim request override these default values. When an authorization request does not specify a list of ACRs explicitly, the value of the default_acr_values is, if set, used as a list of ACRs. The default_acr_values client metadata cannot request the acr claim as essential.

    ​
    Unmet Authentication Requirements

    If the acr claim is requested as an essential claim, the authorization server returns an error response when none of specified ACRs can be satisfied. If the authorization server supports “OpenID Connect Core Error Code unmet_authentication_requirements”, unmet_authentication_requirements is used as the value of the error response parameter. The following is the description about the error code in the specification.
  • unmet_authentication_requirements: The Authorization Server is unable to meet the requirements of the Relying Party for the authentication of the End-User. This error code SHALL be used if the Relying Party wants the OP to conform to a certain Authentication Context Class Reference value using an essential claim acr claim as specified in Section 5.5.1.1. of OpenID Connect Core [OpenID.Core] and the OP is unable to meet this requirement and MAY be used in other cases, if appropriate. If the authorization server does not support the specification, it is up to the authorization server what error code is used.

    ​
    Unmet Authentication Requirements for Step Up Authentication

    In the context of OpenID Connect Core 1.0, no error is reported even if the authorization server cannot perform such user authentication unless the acr claim is requested as essential. However, OAuth 2.0 Step Up Authentication Challenge Protocol recommends that an ACR request by the acr_values request parameter (which requests the acr claim as a voluntary claim) be “treated as required” and the authorization server return the unmet_authentication_requirements error in case none of specified ACRs can be satisfied. The recommendation slightly conflicts with the following paragraph excerpted from OpenID Connect Core 1.0. Note that even if the Claims are not available because the End-User did not authorize their release or they are not present, the Authorization Server MUST NOT generate an error when Claims are not returned, whether they are Essential or Voluntary, unless otherwise specified in the description of the specific claim. However, in practice, the slight conflict won’t be a big issue.

    ​
    Actual ACR Values

    OpenID Connect Core 1.0 does not define actual ACR values. Therefore, to utilize ACR, it is necessary to define actual ACR values in a deployment-specific way. The following table shows examples of actual ACR values.
    DeploymentACR Values
    UK Open Bankingurn:openbanking:psd2:ca urn:openbanking:psd2:sca
    AU CDRurn:cds:au:cdr:2 urn:cds:au:cdr:3
    Open Banking Brasilurn:brasil:openbanking:loa2 urn:brasil:openbanking:loa3
    Authorization servers should advertise information about ACR values they support through their discovery documents. OpenID Connect Discovery 1.0 defines the acr_values_supported server metadata for the purpose as follows.
  • acr_values_supported: OPTIONAL. JSON array containing a list of the Authentication Context Class References that this OP supports.

    ​
    Maximum Authentication Age (Max Age)

    The previous section states “User authentication is performed somewhere during an authorization flow.” at the beginning. However, in practice, the authorization server may skip the user authentication process if it detects that a user has already been authenticated (= if a user has already logged in). Therefore, the time at which an authorization request was made is not necessarily equal to the time of user authentication that was performed for the authorization request. The amount of time that has elapsed since the last user authentication is called “authentication age”. A client application may want to ask the authorization server to redo user authentication during an authorization flow in a case where the authentication age exceeds a particular threshold. The threshold is called “maximum authentication age”.

    ​
    The max_age Request Parameter

    Section 3.1.2.1 of OpenID Connect Core 1.0 defines the request parameter max_age as follows in order to enable client applications to specify the maximum authentication age.
  • max_age: OPTIONAL. Maximum Authentication Age. Specifies the allowable elapsed time in seconds since the last time the End-User was actively authenticated by the OP. If the elapsed time is greater than this value, the OP MUST attempt to actively re-authenticate the End-User. (The max_age request parameter corresponds to the OpenID 2.0 PAPE [OpenID.PAPE] max_auth_age request parameter.) When max_age is used, the ID Token returned MUST include an auth_time Claim Value. The value of the max_age is an integer that represents the maximum authentication age in seconds. It appears in an authorization request like the following. https://as.example.com/authorize?max_age=600&…

    ​
    The default_max_age Client Metadata

    If an authorization request does not contain the max_age request parameter but the default_max_age client metadata of the client is set, the value of the metadata is used as the maximum authentication age. The metadata is defined in Section 2 of OpenID Connect Dynamic Client Registration 1.0 as follows.
  • default_max_age: OPTIONAL. Default Maximum Authentication Age. Specifies that the End-User MUST be actively authenticated if the End-User was authenticated longer ago than the specified number of seconds. The max_age request parameter overrides this default value. If omitted, no default Maximum Authentication Age is specified.

    ​
    The prompt Request Parameter

    When a client application wants to ask the authorization server to perform user authentication unconditionally (regardless of whether the maximum authentication age has been reached or not) during an authorization flow, it can use the prompt request parameter with the login value included. Its use will look like the following. https://as.example.com/authorize?prompt=login&… See Section 3.1.2.1 of OpenID Connect Core 1.0 for details about the prompt parameter.

    ​
    Authentication Requirements Challenge

    Protected resource endpoints that utilize the OAuth 2.0 Step Up Authentication Challenge Protocol specification return an error response when the presented access token does not satisfy either or both of the authentication requirements (namely ACR and Max Age). The diagram below illustrates the flow from returning an error response to making an authorization request asking for an access token that satisfies authentication requirements. Parameters in the error response are explained in the subsequent sections.

    ​
    The insufficient_user_authentication Error Code

    To indicate that the reason of an error response is that authentication requirements are not satisfied, the specification defines an error code insufficient_user_authentication as follows.
  • insufficient_user_authentication: The authentication event associated with the access token presented with the request doesn’t meet the authentication requirements of the protected resource. The error code appears in the WWW-Authenticate HTTP header of an error response as shown below. WWW-Authenticate: Bearer error=“insufficient_user_authentication,…

    ​
    The acr_values Parameter

    To list ACRs one of which an access token must satisfy, the specification defines a parameter acr_values as follows.
  • acr_values: A space-separated string listing the authentication context class reference values, in order of preference, one of which the protected resource requires for the authentication event associated with the access token. The parameter is used in conjunction with the error code insufficient_user_authentication like below (excerpt from the specification): HTTP/1.1 401 Unauthorized WWW-Authenticate: Bearer error=“insufficient_user_authentication”, error_description=“A different authentication level is required, acr_values=“myACR” If a client application receives the error response above, the client application needs to make an authorization request that requests the acr claim as an essential with myACR included in values like below. Line-breaks in the example below are for display purposes only. An actual request does not contain line-breaks. https://as.example.com/authorize?claims= `} }&… If the authorization server treats the acr_values request parameter in the way recommended by the OAuth 2.0 Step Up Authentication Challenge Protocol specification, acr_values=myACR would be enough.

    ​
    The max_age Parameter

    To indicate the maximum authentication age which an access token must satisfy, the specification defines a parameter max_age as follows.
  • max_age: Indicates the allowable elapsed time in seconds since the last active authentication event associated with the access token. The parameter is used in conjunction with the error code insufficient_user_authentication like below (excerpt from the specification): HTTP/1.1 401 Unauthorized WWW-Authenticate: Bearer error=“insufficient_user_authentication, error_description=“More recent authentication is required”, max_age=“5 If a client application receives the error response above, the client application needs to make an authorization request with the prompt request parameter with login included.

    ​
    Authentication Information Bound To Access Token

    To enable protected resource endpoints to check whether a presented access token satisfies authentication requirements or not, the access token must hold information about the user authentication that was performed during the course of issuing the access token. The OAuth 2.0 Step Up Authentication Challenge Protocol specification defines the following two attributes of access token that may appear in the payload part of JWT access tokens and the message body of token introspection responses (cf. RFC 7662).
    AttributeDescription (excerpted from the specification)
    acrAuthentication Context Class Reference. String specifying an Authentication Context Class Reference value that identifies the Authentication Context Class that the user authentication performed satisfied.
    auth_timeTime when the user authentication occurred. A JSON numeric value representing the number of seconds from 1970-01-01T00:00:00Z UTC until the time of date/time of the authentication event.
    The JSON below is an example excerpted from the specification that shows how the acr and auth_time attributes appear in the payload part of JWT access tokens.
Authlete’s Implementation
Authlete supports the OAuth 2.0 Step Up Authentication Challenge Protocol specification since version 2.3.
## Binding Authentication Information
Some Authlete APIs such as the `/auth/authorization/issue` API accept the `acr` request parameter and the `authTime` request parameter which are used as values of the `acr` claim and the `auth_time` claim in the payload of an ID token being issued (cf. [AuthorizationIssueRequest](https://authlete.github.io/authlete-java-common/com/authlete/common/dto/AuthorizationIssueRequest.html)). Authlete 2.3 onwards binds information passed by the request parameters to an access token being issued, too.
The following set of shell commands simulates the authorization code flow ([RFC 6749](https://www.rfc-editor.org/rfc/rfc6749.html) [Section 4.1](https://www.rfc-editor.org/rfc/rfc6749.html#section-4.1)) that issues an access token that holds information about ACR (`acr`) and authentication time (`auth_time`).
(1) Call the `/auth/authorization` API, which receives an authorization request as `parameters` and returns information about the request in JSON format (cf. [AuthorizationResponse](https://authlete.github.io/authlete-java-common/com/authlete/common/dto/AuthorizationResponse.html)).
```shell
curl -v -X POST https://.authlete.com/api//auth/authorization \
-H 'Content-Type: application/json' \
-u 'Authorization: Bearer Service Access Token e.g. Xg6jVpJCvsaXvy2ks8R5WzjdMYlvQqOym3slDX0wNhQ>' \ --data-urlencode parameters="response_type=code&scope=openid&client_id=$&redirect_uri=$&state=$&claims=\"]\`}}}" >\`} authorization_response.json
The value of $ in the command line above needs to be registered in advance as one of “Supported Authentication Context Class References” (which corresponds to the acr_values_supported server metadata). Otherwise, the specified ACR would be ignored. ACR values of an authorization request are listed in the acrs parameter in the response from the /auth/authorization API regardless of where the values come from (acr_values, claims or default_acr_values). In addition, when the acr claim is requested as essential, the boolean parameter acrEssential in the response from the /auth/authorization API holds true. (2) Call the /auth/authorization/issue API, which receives a ticket issued by the /auth/authorization API as ticket, generates tokens (an authorization code, an access token, and/or an ID token), prepares an authorization response that conforms to related standard specifications, and returns JSON (cf. AuthorizationIssueResponse). 
$ TICKET=`jq -r .ticket authorization_response.json`
$ AUTH_TIME=`date +%s`
$ curl -v -X POST https://.authlete.com/api//auth/authorization/issue \
-H 'Content-Type: application/json' \
-u 'Authorization: Bearer Service Access Token e.g. Xg6jVpJCvsaXvy2ks8R5WzjdMYlvQqOym3slDX0wNhQ>' -d ticket=$TICKET -d subject=$SUBJECT -d authTime=$AUTH_TIME -d acr=$ACR >\`} authorization_issue_response.json
```(3) Call the `/auth/token` API, which receives a token request as `parameters`, generate tokens (an access token and optionally an ID token), prepares a token response that conforms to related standard specifications, and returns JSON (cf. [TokenResponse](https://authlete.github.io/authlete-java-common/com/authlete/common/dto/TokenResponse.html)).
```shell
$ AUTHORIZATION_CODE=`jq -r .authorizationCode authorization_issue_response.json`
$ curl -v -X POST https://.authlete.com/api//auth/token \
-H 'Content-Type: application/json' \
-u 'Authorization: Bearer Service Access Token e.g. Xg6jVpJCvsaXvy2ks8R5WzjdMYlvQqOym3slDX0wNhQ>' \
--data-urlencode parameters="client_id=$&grant_type=authorization_code&code=$&redirect_uri=$ -d clientId=$ -d clientSecret=$ >\`} token_response.json
The API call above assumes that the client type of the client is “confidential” and the client authentication method at the token endpoint (token_endpoint_auth_method) is client_secret_basic, which is implied by use of the clientId request parameter and the clientSecret parameter of the /auth/token API (cf. TokenRequest).

​
Unmet Authentication Requirements

Instead of calling the /auth/authorization/issue API, the implementation of the authorization endpoint may call the /auth/authorization/fail API to indicate that the authorization request in question failed. The /auth/authorization/fail API requires the reason request parameter that indicates the reason of the error (cf. AuthorizationFailRequest). When [ACR_NOT_SATISFIED](https://authlete.github.io/authlete-java-common/com/authlete/common/dto/AuthorizationFailRequest.Reason.html#ACR_NOT_SATISFIED) is specified as the value of the reason request parameter, Authlete 2.3 and newer versions prepare an error response whose error is unmet_authentication_requirements to conform to “OpenID Connect Core Error Code unmet_authentication_requirements”. 
curl -v -X POST https://.authlete.com/api//auth/authorization/fail \
-H 'Content-Type: application/json' \
-u 'Authorization: Bearer Service Access Token e.g. Xg6jVpJCvsaXvy2ks8R5WzjdMYlvQqOym3slDX0wNhQ>' \
-d ticket=$TICKET -d reason=ACR_NOT_SATISFIED >\`} authorization_fail_response.json
```The `responseContent` parameter in the response from the `/auth/authorization/fail` API is a URL that points to the redirection endpoint of the client application with the `error` and other parameters (cf. [AuthorizationFailResponse](https://authlete.github.io/authlete-java-common/com/authlete/common/dto/AuthorizationFailResponse.html)).
```shell
$ jq -r .responseContent authorization_fail_response.json
http://localhost:4000/api/mock/redirection/4803170471?error=unmet_authentication_requirements&error_description=%5BA060305%5D+The+authorization+request+requests+%27acr%27+as+essential%2C+but+the+authentication+performed+for+the+end-user+satisfies+none+of+the+requested+ACRs.&error_uri=https%3A%2F%2Fdocs.authlete.com%2F%23A060305&state=917bdc1ef38ba6f6c297b4e31ac84007&iss=https%3A%2F%2Fauthlete.com
```The URL contains the `error_description` parameter unless the `errorDescriptionOmitted` property of the `Service` is `true` (cf. `Service.[isErrorDescriptionOmitted()](https://authlete.github.io/authlete-java-common/com/authlete/common/dto/Service.html#isErrorDescriptionOmitted--)`). The following is the URL-decoded value of the `error_description` parameter.
[A060305] The authorization request requests ‘acr’ as essential, but the authentication performed for the end-user satisfies none of the requested ACRs.
When the authorization request contains `response_mode=form_post` or `response_mode=form_post.jwt`, the value of the `responseContent` parameter in the response from the `/auth/authorization/fail` API is not URL but HTML.
## JWT Access Token
The format of access tokens issued by Authlete is configurable. When the `accessTokenSignAlg` property of `Service` is set (cf. `Service.[getAccessTokenSignAlg()](https://authlete.github.io/authlete-java-common/com/authlete/common/dto/Service.html#getAccessTokenSignAlg--)`), the format of access tokens is JWT (cf. “[Enabling JWT-based access tokens](/kb/oauth-and-openid-connect/jwt-based-access-token)”). Authlete 2.3 and newer versions embed the `acr` and `auth_time` claims into the payload of JWT access tokens as defined in the specification.
When the service is configured to generate JWT access tokens, the `jwtAccessToken` response parameter in responses from the `/auth/token` API holds a JWT access token (cf. [TokenResponse](https://authlete.github.io/authlete-java-common/com/authlete/common/dto/TokenResponse.html)).
```shell
$ JWT_AT=`jq -r .jwtAccessToken token_response.json`
```If you decode the payload part of the JWT access token,
```shell
$ echo $JWT_AT | ruby -paF\\. -rbase64 -e '$_=Base64.urlsafe_decode64 $F[1]' | jq .
```you will find that the `acr` claim and the `auth_time` claim are embedded there.
```json

```## Token Introspection (Standard)
Authlete-powered authorization servers can implement a token introspection endpoint that conforms to [RFC 7662](https://www.rfc-editor.org/rfc/rfc7662.html) by using Authlete’s `/auth/introspection/standard` API. Implementations of protected resource endpoints may use the token introspection endpoint to get detailed information about access tokens.
The `/auth/introspection/standard` API receives a token introspection request as `parameters` and returns JSON (cf. [StandardIntrospectionResponse](https://authlete.github.io/authlete-java-common/com/authlete/common/dto/StandardIntrospectionResponse.html)).
```shell
$ AT=`jq -r .accessToken token_response.json`
$ curl -v -X POST https://.authlete.com/api//auth/introspection/standard \
-H "Content-Type:application/json" \
-u 'Authorization: Bearer Service Access Token e.g. Xg6jVpJCvsaXvy2ks8R5WzjdMYlvQqOym3slDX0wNhQ>' \
--data-urlencode parameters="token=$ >\`} introspection_standard_response.json
```The JSON contains the `responseContent` parameter. The value of the parameter is a JSON string that conforms to [RFC 7662](https://www.rfc-editor.org/rfc/rfc7662.html).
The following command line extracts the value of `responseContent` and parses it as JSON.
```shell
$ jq -r .responseContent introspection_standard_response.json | jq .
```The result of the command line above will look like below. You can find the `acr` property and the `auth_time` property there.
```json

```## Token Introspection (Authlete)
Authlete provides the [/auth/introspection](https://docs.authlete.com/en/shared/latest#post-/api/-serviceId-/auth/introspection) API, which is also for access token introspection but different from the standard introspection endpoint.
Major advantages of the `/auth/introspection` API over the standard introspection endpoint are as follows.
1. Can perform validation that the standard introspection endpoint cannot.
2. Can prepare an error message that conforms to [RFC 6750](https://www.rfc-editor.org/rfc/rfc6750.html).
The `/auth/introspection` API accepts the following request parameters as of this writing (cf. [IntrospectionRequest](https://authlete.github.io/authlete-java-common/com/authlete/common/dto/IntrospectionRequest.html)).
| Parameter | Category | Version | Description |
| --- | --- | --- | --- |
| `token` | Common | 1.1 | An access token to introspect. |
| `scopes` | Common | 1.1 | Scopes that should be covered by the access token. |
| `subject` | Common | 1.1 | The subject (user identifier) that should be associated with the access token. |
| `clientCertificate` | [RFC 8705](https://www.rfc-editor.org/rfc/rfc8705.html) | 2.0 | The client certificate used in the mutual TLS connection established between the client application and the protected resource endpoint. |
| `dpop` | [DPoP](https://www.rfc-editor.org/rfc/rfc9449.html) | 2.2 | The value of the DPoP HTTP header. |
| `htm` | [DPoP](https://www.rfc-editor.org/rfc/rfc9449.html) | 2.2 | The HTTP method of the request to the protected resource endpoint. |
| `htu` | [DPoP](https://www.rfc-editor.org/rfc/rfc9449.html) | 2.2 | The URL of the protected resource endpoint. |
| `resources` | [RFC 8707](https://www.rfc-editor.org/rfc/rfc8707.html) | 2.2 | Resource indicators that should be covered by the access token. |
| `targetUri` | [HTTP Msg Sig](https://www.rfc-editor.org/rfc/rfc9421.html) | 2.3 | The full URL of the request. |
| `headers` | [HTTP Msg Sig](https://www.rfc-editor.org/rfc/rfc9421.html) | 2.3 | The HTTP headers to be included in processing the signature. |
| `requestBodyContained` | [HTTP Msg Sig](https://www.rfc-editor.org/rfc/rfc9421.html) | 2.3 | Whether the request contains a message body. |
| `acrValues` | [Step Up Auth](https://www.rfc-editor.org/rfc/rfc9470.html) | 2.3 | The list of Authentication Context Class Reference values one of which the user authentication performed during the course of issuing the access token must satisfy. |
| `maxAge` | [Step Up Auth](https://www.rfc-editor.org/rfc/rfc9470.html) | 2.3 | The maximum authentication age which is the maximum allowable elapsed time since the user authentication was performed during the course of issuing the access token. |
Request parameters except `token` are related to access token validation. Ones to pay attention to here are the `acrValues` request parameter and the `maxAge` request parameter.
### ACR validation
If the `acrValues` request parameter is supplied, the `/auth/introspection` API checks whether the ACR bound to the given access token is included in the `acrValues` array. If the ACR is not included, the API prepares an error response that conforms to the OAuth 2.0 Step Up Authentication Challenge Protocol specification.
The following command line lets the `/auth/introspection` API validate ACR.
```shell
$ curl -v -X POST https://.authlete.com/api//auth/introspection \
-H 'Content-Type:application/json' \
-u 'Authorization: Bearer Service Access Token e.g. Xg6jVpJCvsaXvy2ks8R5WzjdMYlvQqOym3slDX0wNhQ>'  \
-d token=$AT -d acrValues="acrX acrY >\`} introspection_response-acrValues.json
```The `responseContent` parameter in the response from the API (cf. [IntrospectionResponse](https://authlete.github.io/authlete-java-common/com/authlete/common/dto/IntrospectionResponse.html)) holds a string that should be used as the value of the `WWW-Authenticate` HTTP header. You will see that (a) the value of `error` is `insufficient_user_authentication` and (b) `acr_values` is included.
```shell
$ jq -r .responseContent introspection_response-acrValues.json
Bearer error="insufficient_user_authentication",error_description="[A341302] The authentication context class 'acr1' of the user authentication that the authorization server performed during the course of issuing the access token is insufficient. User authentication of an access token must satisfy one of [acrX acrY] to access the protected resource.,error_uri="https://docs.authlete.com/#A341302",acr_values="acrX acrY
```### Max Age Validation
If the `maxAge` request parameter is supplied, the `/auth/introspection` API checks whether the specified time has elapsed since the user authentication time bound to the given access token. If the time has elapsed, the API prepares an error response that conforms to the OAuth 2.0 Step Up Authentication Challenge Protocol specification.
The following command line lets the `/auth/introspection` API validate authentication time.
```shell
$ curl -v -X POST https://.authlete.com/api/{serviceId}/auth/introspection \
-H 'Content-Type:application/json' \
-u 'Authorization: Bearer Service Access Token e.g. Xg6jVpJCvsaXvy2ks8R5WzjdMYlvQqOym3slDX0wNhQ>'  \
-d token=$AT -d maxAge=600 >\`} introspection_response-maxAge.json
```In this case, the string for the `WWW-Authenticate` HTTP header contains `max_age`.
```shell
$ jq -r .responseContent introspection_response-maxAge.json
Bearer error="insufficient_user_authentication",error_description="[A340301] The time of the user authentication that the authorization server performed during the course of issuing the access token is too old, so re-authentication is needed. The maximum authentication age (max_age) required by the protected resource is 600.,error_uri="https://docs.authlete.com/#A340301",max_age="600"
```# Finally
We released Authlete 3.0 in November 2024 ([announcement](https://www.authlete.com/news/20241106_authlete3/)). Naturally, it supports the OAuth 2.0 Step Up Authentication Challenge Protocol. Please take full advantage of it!
#### On this page
- [Authentication Context Class Reference (ACR)](#authentication-context-class-reference-acr)
  [The acr_values Request Parameter](#the-acr_values-request-parameter)
  [The claims Request Parameter](#the-claims-request-parameter)
  [The default_acr_values Client Metadata](#the-default_acr_values-client-metadata)
  [Unmet Authentication Requirements](#unmet-authentication-requirements)
  [Unmet Authentication Requirements for Step Up Authentication](#unmet-authentication-requirements-for-step-up-authentication)
  [Actual ACR Values](#actual-acr-values)
- [Maximum Authentication Age (Max Age)](#maximum-authentication-age-max-age)
  [The max_age Request Parameter](#the-max_age-request-parameter)
  [The default_max_age Client Metadata](#the-default_max_age-client-metadata)
  [The prompt Request Parameter](#the-prompt-request-parameter)
- [The insufficient_user_authentication Error Code](#the-insufficient_user_authentication-error-code)
- [The acr_values Parameter](#the-acr_values-parameter)
- [The max_age Parameter](#the-max_age-parameter)
- [Binding Authentication Information](#binding-authentication-information)
- [Unmet Authentication Requirements](#unmet-authentication-requirements-1)
- [JWT Access Token](#jwt-access-token)
- [Token Introspection (Standard)](#token-introspection-standard)
- [Token Introspection (Authlete)](#token-introspection-authlete)
  [ACR validation](#acr-validation)
  [Max Age Validation](#max-age-validation)