OPRevocation

File(s): conf/relying-party.xml, conf/oidc.properties
Format: Native Spring, Spring Properties

Overview

The OAuth2.Revocation profile configuration bean enables support for the OAuth2 Token Revocation profile, living at /idp/profile/oauth2/revocation

This implementation requires client authentication and requires that the client_id match either the value in the token or one of the audiences of the token to permit the operation.

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 common to all OAuth2/OIDC profiles:

Name	Type	Default	Description

Name	Type	Default	Description
securityConfiguration	JSONSecurityConfiguration	Bean named shibboleth.oidc.DefaultSecurityConfiguration	An object containing all of the default security-related objects needed for peer authentication and encryption. See OIDCSecurityConfiguration for complete details.
messageHandler ^4.2	Function<MessageContext,Exception>		A function hook allowing modification of messages before signing and transmission, useful for adding extensions
inboundInterceptorFlows	List<String>		Ordered list of profile interceptor flows to run prior to message processing
outboundInterceptorFlows	List<String>		Ordered list of profile interceptor flows to run prior to outbound message handling

Guidance

Modifying the security configuration is usually done to:

specify an alternate signing or decryption key to use
control signing or encryption algorithms

The two interceptor lists allow the much less commonly used profile interceptor injection points to be used. This is largely a Java-based way of doing very low-level sorts of “message rewriting” hackery that might otherwise be impossible to pull off. One use case for the inbound side might be picking up non-standard parameters in a request.

The use of DPoP proofs in the revocation endpoint is not required by default. The default behaviour may be changed via requireDpopProof -option.

Options related to DPoP proof validation:

Name	Type	Default	Description

Name	Type	Default	Description
requireDpopProof ^4.2	Boolean	false	A flag for requiring the DPoP proof JWT in the profile. If the proof exists in the request, it’s always validated.
dpopProofClaimsValidator ^4.2	ClaimsValidator	Beans named DefaultDPoPProofClaimsValidator for PAR/token and DefaultDPoPWithAthProofClaimsValidator for others (involving access token validation)	The claims validation configuration used for validating the payload contents of the DPoP proof JWTs. The default values follows the RFC: the latter also verifying the access token hash claim.
dpopProofSignatureValidationConfiguration ^4.2	BasicSignatureValidationConfiguration	Bean named DPoPSignatureValidationConfiguration	The bean used for defining the signature validation configuration used for validating DPoP proof signatures.
dpopProofNonceGenerator ^4.2	Function< ProfileRequestContext, String>	Bean named DefaultOAuth2DPoPNonceGenerator	The bean used for defining the function used for generating nonce used within DPoP proofs. Null value (`#{null}`) means that nonces are disabled. If modified to a non-null value, the `dpopProofClaimsValidator`needs to be modified to be able to validate the custom nonce value.

DPoP proof claims set validation

The idp.policy.messageLifetimeand idp.policy.clockSkew properties are exploited when validating the iat -claim.

Replay detection

The DPoP proofs must contain a unique identifier (jti -claim). The default validation (the dpopProofClaimsValidator option) implements this check via shibboleth.ReplayCachebean, which exploits the storage service that may be configured via idp.replayCache.StorageService -property (see https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199509576/StorageConfiguration#Reference ).

The lifetime for the replay cache record is taken from the exp -claim if it exists in the DPoP proof claims set. If not, the property idp.oauth2.dpop.replayCacheLifetime(defaults to 5 minutes) is exploited. The record key is taken from the jti claim.

In order to guard against memory exhaustion attacks, the jti values longer than 64 characters are hashed with SHA-256 before using them as the replay record key. The maximum record lifetime may also be set via idp.oauth2.dpop.maxReplayCacheLifetime-property, which defaults to 5 minutes.

Nonces

If the dpopProofNonceGenerator option has a value, the bean is used for generating nonce values to be used within DPoP proof JWTs. The default value points to an implementation that generates relying party -specific values that are valid for 5 minutes, customisable via idp.oauth2.dpop.nonceLifetime-property. The default implementation exploits the data sealer for encrypting the nonce value into an opaque string.

The default value for dpopProofClaimsValidator contains a claims validator that is activated whenever dpopProofNonceGenerator option has a value.

Note that any browser-based client applications using CORS may require the DPoP-Nonce to be included in the Access-Control-Expose-Headers response header list value. The page https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199501090 describes some alternatives for handling CORS preflight requests. For instance the Spring CORS configuration supports p:exposedHeaders="DPoP-Nonce"as a way for satisfying that requirement.

Options common to OP profiles that support client authentication:

Name	Type	Default	Description

Name	Type	Default	Description
tokenEndpointAuthMethods	Collection<String>	client_secret_basic, client_secret_post, client_secret_jwt, private_key_jwt	Enabled endpoint client authentication methods for the profile. Note that the RP metadata also needs to set the token endpoint authentication method: the default value when it’s not set is `client_secret_basic`. Also note that the method `none` for public clients that cannot authenticate is not included in the list of default values. Similarly to other methods, it needs to be enabled in the profile with this option and also set in the RP metadata.
useTargetedEndpointAsJWTAudience^4.3	Boolean	true	Flag to enable use of endpoints (the token or target endpoint) in the JWT client authentication audience
requireSingleJWTAudience^4.3	Boolean	false	Flag to require single value in the JWT client authentication audience
clientAuthenticationJWTType^4.3	String		Mandatory value for the `typ` header used within JWT authentication
unregisteredClientPolicy^4.0	Map<String, UnregisteredClientPolicy>	See wiki page	The policy used to verify unverified clients when this profile is enabled in the unverified RP config

Since OP v3.4, the JWT-based client authentication methods (client_secret_jwt and private_key_jwt) accepts any of the following three audiences:

OP issuer value (profile responder ID)
The token flow endpoint URL value (even for introspection and revocation endpoints)
The flow endpoint URL value

For convenience, the following methods also exist for globally control the default values:

Property idp.oauth2.jwtAuth.targetedEndpointAsJWTAudience^4.3
Property idp.oauth2.jwtAuth.requireSingleJWTAudience^4.3
Any custom bean for validating the audience can be set via idp.oauth2.jwtAuth.audienceValidator -property.

For convenience, the enabled client authentication methods are also controllable globally via the idp.oidc.tokenEndpointAuthMethods property.

Options specific to this profile are:

Name	Type	Default	Description

Name

Type

Default

Description

revocationMethod

CHAIN or TOKEN

CHAIN

The revocation method:

CHAIN refers to revoking the entire chain of tokens (the authorization code and all access/refresh tokens issued based on it)
TOKEN refers to revoking a single token

revocationLifetime

Duration

PT6H

The revocation lifetime used when revoking the full chain (see CHAIN above).

For convenience, revocationMethod is globally controllable via the idp.oauth2.revocationMethod property and revocationLifetime via the idp.oidc.revocationCache.authorizeCode.lifetime property. If a single token is to be revoked, the lifetime is taken from the remaining lifetime of the token to be revoked. It’s calculated by comparing the expiration time of the token to the current instant. See OPToken | Configuration for the configuration of lifetimes for access and refresh tokens.