Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Expand
titleProfile-Specific

Options specific to the OIDC Authorization flow:

Name

Type

Default

Description

iDTokenLifetime

Duration

PT1H

Lifetime of ID token

accessTokenLifetime

Duration

PT10M

Lifetime of access token

authorizeCodeLifetime

Duration

PT5M

Lifetime of authorization code

refreshTokenLifetime

Duration

PT2H

Lifetime of refresh token

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

accessTokenType3.2

String

 

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

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.

The following properties can be used to globally adjust some of the settings above (some of them affect other profiles as well).

  • idp.oidc.idToken.defaultLifetime

  • idp.oidc.accessToken.defaultLifetime

  • idp.oidc.authorizeCode.defaultLifetime

  • idp.oidc.refreshToken.defaultLifetime

  • idp.oidc.forcePKCE

  • idp.oidc.allowPKCEPlain

  • idp.oidc.encodedAttributes

  • idp.oidc.encodeConsentInTokens

  • idp.oidc.alwaysIncludedAttributes

  • idp.oidc.deniedUserInfoAttributes

The encodedAttributes feature is discussed under OPAttributeResolution (see Timing of Resolution).

The final two options relate to "claims splitting" and override the typical processing rules for when to insert claims into particular tokens. Typically most "data" is omitted from the front-channel ID token unless no authorization code is being issued, with the claims only accessed via the UserInfo endpoint. These settings force claims into or out of those spots.

...