OPReleaseNotes

4.3.0 (June 23, 2025)

This is a feature release accompanying a new version of the OIDC commons library and OIDC config module along with some general improvements. It is compatible with Shibboleth IdP 5.0 or later.

JWT client authentication configuration

An Audience Injection Attack for, amongst others, private key JWT client authentication is discussed in a research paper. The paper outlines a mitigation strategy. This strategy involves setting the value of the audience (aud) claim in a JWT assertion to match the issuer identifier of the OP instead of the token (or target) endpoint URL. This approach is also suggested by the draft RFC.

While we still keep the default configuration intact, we provide new profile configuration options to easily enforce the suggested changes:

• useTargetedEndpointAsJWTAudience: Flag to enable use of endpoints (the token or target endpoint) in the JWT client authentication audience (defaults to true)

• requireSingleJWTAudience: Flag to require single value in the JWT client authentication audience (defaults to false)

• clientAuthenticationJWTType: Mandatory value for the typ header used within JWT authentication (default to null, meaning any or missing value is accepted)

A mitigation strategy is described here: https://shibboleth.atlassian.net/wiki/spaces/IDPPLUGINS/pages/4484497465 .

Administrative token revocation

The administrative token revocation feature is a way to address the need to disrupt existing tokens with the IdP in the event of account compromise.

A new condition (actually a BiPredicate) attached to token, user info and introspection flows (usually globally via some simple properties) determines whether a particular JWTClaimsSet is revoked, and if configured to do so the OP will check this condition as a part of the token validation.

The feature is documented here: https://shibboleth.atlassian.net/wiki/spaces/IDPPLUGINS/pages/4487053313 .

Audit logging improvements

Similarly to the other IdP authentication flows, now also the authn/OAuth2Client flow supports audit logging. All available audit logging fields are documented at https://shibboleth.atlassian.net/wiki/spaces/IDPPLUGINS/pages/2929033287 .

For generic audit logging messages, previously unwired %DEST is now wired to contain validated redirection URI value within PAR, authorize and token flows.

New configuration properties

• idp.oauth2.jwtAuth.targetedEndpointAsJWTAudience: Flag to enable use of endpoints (the token or requested endpoint) in the JWT client authentication audience (defaults to true)

• idp.oauth2.jwtAuth.requireSingleJWTAudience: Flag to require single value in the JWT client authentication audience (defaults to false)

• idp.oauth2.revocationCondition: Bean ID to implement the condition of type BiPredicate<ProfileRequestContext,JWTClaimsSet> (defaults to shibboleth.BiConditions.FALSE)

• idp.oauth2.revocationCondition.attributeId: Attribute ID used by shibboleth.oauth2.AttributeTokenRevocationCondition for timestamp before all the principal’s tokens are considered as revoked (defaults to revocation)

• idp.authn.OAuth2Client.audit.enabled: Flag to enable authentication flow audit logging (defaults to idp.authn.audit.enabled, which defaults to false)

• idp.authn.OAuth2Client.audit.category: Logging category for authentication flow audit logging (defaults to Shibboleth-Audit.OAuth2Client)

• idp.authn.OAuth2Client.audit.format: Formatting map for authentication flow audit logging

New configuration beans

• shibboleth.oauth2.AttributeTokenRevocationCondition: Bean that can be used for administrative token revocation (also see idp.oauth2.revocationCondition.attributeId -property)

• shibboleth.authn.OAuth2Client.AuditExtractors: Bean to override default map of audit value extractors

4.2.1 (January 28, 2025)

This is a patch release, addressing a regression bug related to the use of frontChannelSuccess-option within logout propagation.

4.2.0 (October 23, 2024)

This is a feature release accompanying a new version of the OIDC commons library along with some general improvements and bug fixes. It is compatible with Shibboleth IdP 5.0 or later.

This release addresses security advisory (https://shibboleth.net/community/advisories/secadv_20241023.txt) related to a pair of race conditions in the authorization/authentication request processing.

Request object handling

In addition to the OIDC-specified request object handling, the plugin now also supports OAuth2 JWT-secured authorization requests (JAR). This logic is applied to the non-OIDC authorization requests to the authorization-endpoint and to all pushed authorization requests (see PAR below).

PAR endpoint

The plugin now supports 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 (API) request. The server provides them with a request URI that is used as a reference to the data in a subsequent call to the authorization endpoint. We provide two methods for the request URI generation: the default method encrypts the state inside the value. The other method exploits a configurable storage service: this way the values remain shorter as the URI value only contains a reference to the storage record.

The full profile documentation is available at https://shibboleth.atlassian.net/wiki/spaces/IDPPLUGINS/pages/3712647169 .

DPoP access tokens

In addition to the bearer tokens, the plugin now supports OAuth2 demonstrating proof of possession (DPoP) specification. As described in the RFC: “DPoP can be used to sender-constrain access tokens regardless of the client authentication method employed, but DPoP itself is not used for client authentication. DPoP can also be used to sender-constrain refresh tokens issued to public clients (those without authentication credentials associated with the client_id).”.

The DPoP tokens are now automatically issued to the clients that use valid DPoP proof JWTs in the token request. Several profile configuration options are available for enforcing and customizing the default logic.

Custom request/response message handling

The plugin now offers additional hooks for customizing the request message parsing and the creation of the successful and error response objects. The https://shibboleth.atlassian.net/wiki/spaces/IDPPLUGINS/pages/3785326593/OPMessageHandling?atl_f=content-tree page describes the current features. Similarly to the SAML profiles, the new messageHandler profile configuration option is now available for OAuth2/OIDC profiles too.

It should be noted that the position of the call to outbound interceptor flows was changed to occur right after the creation of the response message: the logic is now compliant with the one used in the SAML profiles. Previously wired outbound interceptor flows should thus be verified to be interoperable.

New configuration properties

• idp.oauth2.par.StorageService: the storage service to be used for storing pushed authorization requests (defaults to in-memory)

• idp.oauth2.par.serializationStrategies: a bean containing a map of serialization strategies for the pushed authorization requests (defaults to shibboleth.oidc.DefaultPushedAuthorizationRequestUriSerializationStrategies)

• idp.oauth2.par.requestUriType: the pushed authorization request URI value type (default to empty, referring to the method encrypting the state inside the opaque value)

• idp.oauth2.par.requestUriLifetime: the pushed authorization request URI lifetime (defaults to 1 minute)

• idp.oauth2.dpop.replayCacheLifetime: the replay cache record lifetime if the DPoP proof doesn’t contain expiration time (defaults to 5 minutes)

• idp.oauth2.dpop.maxReplayCacheLifetime: upper bound of the DPoP proof lifetime in the replay cache (defaults to 5 minutes)

• idp.oauth2.dpop.proofAlgorithms: the algorithms advertised to be compatible for DPoP proofs, defaults to RS256,RS384,RS512,PS256,PS384,PS512,ES256,ES384,ES512

• idp.oauth2.par.useOnlyRequestObject: the bean for condition to use only values from request objects within PAR-endpoint (defaults to JAR-logic, i.e. if request object is specified, the values are only fetched from there)

• idp.oauth2.authorize.useOnlyRequestObject: the bean for condition to use only values from request objects within authorisation-endpoint

• idp.oidc.strictScopeValidation: a flag to use strict scope validation, i.e. a request for unallowed scope leads to an error (defaults to false)

• idp.oidc.requestParser.*: request-message specific custom parsers as described in https://shibboleth.atlassian.net/wiki/spaces/IDPPLUGINS/pages/3785326593/OPMessageHandling?atl_f=content-tree.

New configuration beans

• shibboleth.oidc.MetadataPolicyRedirectUriValidator: Abstract bean can be used for wiring metadata policy -based custom validators

• shibboleth.oauth2.par.AllowedScopeStrategy: Allowed scope lookup strategy for PAR

• shibboleth.oidc.par.SignedRequestObjectClaimsValidation: Chain of validators for request object in the PAR endpoint

• shibboleth.oidc.DefaultOAuth2ProtectedApiMappedErrors: New error-mapping bean to be used with the OAuth2 protected endpoints, see https://shibboleth.atlassian.net/wiki/spaces/IDPPLUGINS/pages/3785326593/OPMessageHandling#Error-handling

4.1.0 (April 11, 2024)

This is a feature release accompanying a new version of the OIDC commons library along with some general improvements and minor bug fixes. It is compatible with Shibboleth IdP 5.0 or later.

General Note

There is a bug in the Nimbus library we use for much of the functionality in the OP that impacts the way we set and manage cookies within the IdP. This bug manifests in a fairly complex way and was exposed by a fix in V5.1.3 that causes the behaviour to be worse there than before, but there are limitations even on older versions. For versions older than 4.2.0, the following should be taken into account if you run without HTML Local Storage enabled for tracking client sessions:

V5.1.3+