File(s): conf/relying-party.xml, conf/oidc.properties
Format: Native Spring, Spring Properties
Overview
The OAuth2.Introspection profile configuration bean enables support for the OAuth2 Token Introspection profile, living at /idp/profile/oauth2/introspection
Supported response parameters are: active, scope, client_id, username, token_type, exp, iat, sub, iss, and aud.
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 allow an accurate response.
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.
Common
Options common to most/all profiles:
Name | Type | Default | Description |
|---|
securityConfiguration | SecurityConfiguration | Bean named shibboleth.DefaultSecurityConfiguration | An object containing all of the default security-related objects needed for peer authentication and encryption. See SecurityConfiguration for complete details. |
disallowedFeatures | Integer | 0 | A bitmask of features to disallow, the mask values being specific to individual profiles |
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 (but for metadata you control, it's advisable to control algorithms by using an extension to specify supported 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 SAML request.
Client Authentication
Options common to OP profiles that support client authentication:
Name | Type | Default | Description |
|---|
tokenEndpointAuthMethods | Collection<String> | client_secret_basic,
client_secret_post,
client_secret_jwt,
private_key_jwt | Enabled endpoint client authentication methods |
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 |
For convenience, this is also controllable globally via the idp.oidc.tokenEndpointAuthMethods property.
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
Prior to V3.4, only the flow endpoint URL value could be used. Any custom bean for validating the audience can be set via idp.oauth2.jwtAuth.audienceValidator -property.
For convenience, this is also controllable globally via the idp.oidc.dynreg.tokenEndpointAuthMethods property.