Page Comparison

iDTokenLifetime

Duration

PT1H

Lifetime of ID token

accessTokenLifetime

Duration

PT10M

Lifetime of access token

If you customise this, make sure to set the revocation cache lifetime (See Replay and Revocation -section later at this page) to at least match with this. Also check refreshTokenTimeout and use which ever is longer.

authorizeCodeLifetime

Duration

PT5M

Lifetime of authorization code

refreshTokenLifetime

Duration

PT2H

DEPRECATED

Lifetime of refresh token

refreshTokenTimeout ^3.4

Duration

PT2H

Lifetime of a single refresh token issued to client, which acts as a timeout on the ability to refresh any tokens.

If you customise this, make sure to set the revocation cache lifetime (See Replay and Revocation -section later at this page) to at least match with this. Also check accessTokenLifetime and use which ever is longer.

refreshTokenChainLifetime ^3.4

Duration

PT2H

Lifetime of the chain of refresh tokens issued to client. The expiration instant is calculated by adding the lifetime to the end user authentication instant.

additionalAudiencesForIdToken

Set<String>

Adds additional valid audiences for ID token. This feature does not involve any policy controls or features that may be added in the future to support issuing tokens to parties other than the OIDC client. It should be used with caution, and in most cases avoided.

acrRequestAlwaysEssential

Boolean

false

Whether to treat "acr" claim requests as essential regardless of request

forcePKCE

Boolean

false

Whether client is required to use PKCE

allowPKCEPlain

Boolean

false

Whether client is allowed to use PKCE code challenge method "plain"

encodedAttributes

Set<String>

Specifies IdPAttributes to encode into tokens for recovery on back-channel token requests

encodeConsentInTokens

Boolean

false

Whether to embed consent decision(s) in access/refresh tokens and authorization code to allow for client-side consent storage

alwaysIncludedAttributes

Set<String>

Specifies IdPAttributes to always include in ID token regardless of response_type

deniedUserInfoAttributes

Set<String>

Specifies IdPAttributes to omit from UserInfo token

accessTokenType^3.2

String

Format of access token. Supported values are “JWT” or nothing/empty/null, implying opaque tokens.

useRequestObject ^3.4

Boolean

false

Whether to enforce use of request objects

signRequestObject ^3.4

Boolean

true

Whether to enforce signing of request objects if they’re used.

encryptRequestObject ^3.4

Boolean

false

Whether to enforce encryption of request objects if they’re used.

responseModes ^4.1

Set<String°

Specifies allowed values for response_mode in the authorization/authentication requests. Null/empty means that all supported values are allowed.

requireAuthenticationRequest ^4.1

Boolean

true

Whether to enforce use of OIDC authentication sequence (involving openid scope).

Note! In SAML metadata-driven configuration, only the use of requireAuthenticationRequestPredicate is supported.

requirePushedAuthorizationRequest ^4.2

Boolean

false

Whether to require the use of OAUTH2.PAR prior to the authorization/authentication request and thus include the request_uri value produced by it.

includeIssuerInResponse ^3.2

Boolean

false

Whether to include issuer -parameter in the responses, as specified by RFC 9207. If set to true, also consider including authorization_response_iss_parameter_supported to the OP metadata.

IDTokenManipulationStrategy ^3.2

BiFunction<
ProfileRequestContext,
Map<String,Object>,
Map<String,Object>
>

Manipulation strategy for customising id_token contents. The BiFunction inputs are the ProfileRequestContext and the current contents of id_token as a Map<String,Object>.

If the result is non-null, the result (Map<String,Object) is used to replace the contents of the id_token. It is the deployer’s responsibility to ensure the results remain valid/appropriate.

authorizationCodeClaimsSetManipulationStrategy ^3.2

BiFunction<
ProfileRequestContext,
Map<String,Object>,
Map<String,Object>
>

Manipulation strategy for customising authorization code claims set contents. The BiFunction inputs are the ProfileRequestContext and the current contents of the claims set as a Map<String,Object>.

If the result is non-null, the result (Map<String,Object) is used to replace the contents of the claims set. It is the deployer’s responsibility to ensure the results remain valid/appropriate. 

accessTokenClaimsSetManipulationStrategy ^3.2

BiFunction<
ProfileRequestContext,
Map<String,Object>,
Map<String,Object>
>

Manipulation strategy for customising access token claims set contents. The BiFunction inputs are the ProfileRequestContext and the current contents of the claims set as a Map<String,Object>.

If the result is non-null, the result (Map<String,Object) is used to replace the contents of the claims set. It is the deployer’s responsibility to ensure the results remain valid/appropriate.

customRedirectUriValidationStrategy ^4.2

BiPredicate<

URI,

ProfileRequestContext

>

null

Custom validation strategy for the redirect_uri parameter. If a value is set, it overrides the default validation logic for both registered and unregistered clients.