This profile configuration was introduced in V3.1 of this plugin. In older releases, it was implicitly part of the OIDC.SSO profile configuration and was not a separate feature.
File(s):conf/relying-party.xml, conf/oidc.properties Format: Native Spring, Spring Properties
The OAUTH2.Token profile configuration bean enables support for the OAUTH 2 Token endpoint, which implements the flow that supports OAuth token granting use cases, including OIDC-specific grant features in support of that particular use case.
In V3.1+ of the plugin, the behavior of the Authorization and Token endpoints has been optionally split into separate profile configurations, in order to support additional OAuth use cases specific to the token endpoint and to allow for more configuration flexibility. When this profile bean is absent, the presence of the OIDC.SSO profile configuration bean implies the OIDC-specific functionality of this endpoint is active with the settings configured on that bean. When present, it supersedes that behavior and directly configures all uses of the endpoint.
Configuration
The most typical options used are described in more detail below, but not every obscure option is discussed. See the javadoc for all of the possible configuration options for this profile (note that some of them are inherited from parent classes).
Virtually all the configuration options below can be set via two different properties: a static property that explicitly sets the value to use and a lookup strategy or predicate property that takes a Function or Predicate and returns the value to use. The dynamic property is generally named "propertyNamePredicate" or "propertyNameLookupStrategy" for Boolean- and non-Boolean-valued properties respectively.
Options specific to generic or OAuth usage of the Token flow:
Name
Type
Default
Description
Name
Type
Default
Description
resolveAttributes
Boolean
true
Whether to resolve attributes during the token issuance process
grantTypes
Collection<String>
authorization_code, refresh_token
OAuth grant types to allow
accessTokenLifetime
Duration
PT10M
Lifetime of access token issued to client
If you customize this, make sure to set the revocation cache lifetime (See Replay and Revocation section later at this page) to at least this length of time. Also check refreshTokenTimeout and use whichever is longer.
refreshTokenLifetime
Duration
PT2H
Lifetime of refresh token issued to client (Deprecated since 3.4)
refreshTokenTimeout 3.4
Duration
PT2H
Lifetime of a single refresh token issued to client
If you customize this, make sure to set the revocation cache lifetime (See Replay and Revocation section later at this page) to at least this length of time. Also check accessTokenLifetime and use whichever 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.
forcePKCE
Boolean
false
Whether client is required to use PKCE
allowPKCEPlain
Boolean
false
Whether client is allowed to use PKCE code challenge method "plain"
accessTokenType 3.2
String
Format of access token. Supported values are “JWT” or nothing/empty/null, implying opaque tokens.
refreshTokenType 4.1
String
Format of refresh token. Supported values are “JWT” or nothing/empty/null, implying opaque tokens.
enforceRefreshTokenRotation 3.2
Boolean
false
Whether to enforce refresh token rotation. If enabled, the refresh token is revoked whenever it is used for issuing a new refresh token.
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.
Manipulation strategy for customising refresh 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.oauth2.grantTypes
idp.oidc.accessToken.defaultLifetime
idp.oidc.refreshToken.defaultLifetime (deprecated since v3.4)
Options specific to the use of OIDC with the Token flow (in addition to the OAuth settings above):
Name
Type
Default
Description
Name
Type
Default
Description
encryptionOptional
Boolean
true
Whether the absence of encryption details in a client’s metadata should fail when issuing an ID token
iDTokenLifetime
Duration
PT1H
Lifetime of ID token issued to client
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.
alwaysIncludedAttributes
Set<String>
Specifies IdPAttributes to always include in ID token regardless of response_type
issueIdTokenViaRefreshToken 3.4
Boolean
true
Whether to issue id_token when refresh_token grant type is used.
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.
The following properties can be used to globally adjust some of the settings above (some of them affect other profiles as well).
idp.oauth2.encryptionOptional
idp.oidc.idToken.defaultLifetime
idp.oidc.alwaysIncludedAttributes
idp.oidc.issueIdTokenViaRefreshToken 3.4
The final option relates 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. This setting forces claims into or out of the ID token.
Replay and Revocation
Authorization codes are bearer tokens and have to be limited to a single use as a security measure. Reuse is monitored by storing reference values in the existing IdP replay cache that handles related SAML and CAS needs. It should be noted that the criticality of this cache to CAS and OIDC are generally much higher than for SAML (unless SAML artifacts are used), and the limitations of an in-memory cache that is not clustered across servers much more severe.
Reuse of an authorization code invalidates all tokens derived from it by tracking revoked codes. This is handled by another (obviously server-side) cache, the revocation cache.
Two properties are provided in conf/oidc.properties to control aspects of this process:
idp.oidc.revocationCache.authorizeCode.lifetime
Lifetime of entries stored in the revocation cache (covering the entire token chain), defaults to 6 hours.