Overview
Since OP version 4.2, the OAUTH2.PAR profile configuration bean enables support for OAuth2 Pushed Authorization Requests (PAR), a method for clients to push the payload of an OAuth 2.0 authorization request to AS/OP via a direct request and provides them with a request URI that is used as reference to the data in a subsequent call to the authorization endpoint.
Configuration
The requestUriType option can be used for defining the type how the resulting request_uri values are produced. The default (empty) value refers to the use of opaque format: it encodes all the requested parameters inside the token which is encrypted via data sealer. The benefit is that no server-side state is needed, but very long request parameter values may cause its length to exceed 512 ASCII characters, which is not recommended by the specs. The value “ss” refers to the use of configurable storage service: then the value remain short but the same storage must be available for authorization endpoint (OIDC.SSO profile) when the request_uri is used.
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.
Flow Types
Options common to OP profiles with OIDC flow settings:
Name | Type | Default | Description |
|---|
authorizationCodeFlowEnabled | Boolean | true | Whether to enable the authorization code flow |
hybridFlowEnabled | Boolean | true | Whether to enable the hybrid flow |
implicitFlowEnabled | Boolean | true | Whether to enable the implicit flow |
refreshTokensEnabled | Boolean | true | Whether to enable refresh token support |
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.tokenEndpointAuthMethods property.
Profile-Specific
Options specific to the PAR flow:
Name | Type | Default | Description |
|---|
forcePKCE | Boolean | false | Whether client is required to use PKCE |
allowPKCEPlain | Boolean | false | Whether client is allowed to use PKCE code challenge method "plain" |
useRequestObject | Boolean | false | Whether to enforce use of request objects |
signRequestObject | Boolean | true | Whether to enforce signing of request objects if they’re used. |
encryptRequestObject | Boolean | false | Whether to enforce encryption of request objects if they’re used. |
responseModes | Set<String> | | Specifies allowed values for response_mode in the authorization/authentication requests. Null/empty means that all supported values are allowed. |
requireAuthenticationRequest | 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. |
customRedirectUriValidationStrategy | 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. |
requestUriType | String | | Format of request_uri. Supports values are “ss” or nothing/empty/null, implying opaque tokens. “ss” refers to the use of storage service (defined byidp.oauth2.par.StorageService, defaulting to in-memory service): this way the values remain shorter as the URI value only contains a reference to the storage record. |
requestUriLifetime | Duration | PT1M | Lifetime for the request_uri to remain valid |
requestUriClaimsSetManipulationStrategy | BiFunction<
ProfileRequestContext,
Map<String,Object>,
Map<String,Object>
> | | Manipulation strategy for customising request_uri claims set contents. The BiFunction inputs are the ProfileRequestContext and the current contents of request_uri 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.oidc.forcePKCE
idp.oidc.allowPKCEPlain
idp.oauth2.requireAuthenticationRequestPredicate
idp.oidc.requestobject.used
idp.oidc.requestobject.signed
idp.oidc.requestobject.encrypted
idp.oauth2.responseModes
idp.oauth2.par.requestUriType
idp.oauth2.par.requestUriLifetime
idp.oauth2.par.serializationStrategies
idp.oauth2.par.StorageService