OAuth 2.0 / OpenID Connect SDK v9.0

The OAuth 2.0 / OpenID Connect SDK for developing client and server applications has a new major release today.

The underlying Nimbus JOSE+JWT library was upgraded to major version 9.0, which made appearance in 2020 and most notably shaded the JSON Smart dependency. If your framework or application code relies on methods from the JWT library that return JSON Smart classes (JSONObject or JSONArray) and doesn't compile you will need to refactor it. The JSONObjects.toJSONString utility can help you with serialising JSON.

The reported bugs in the tracker were also run down to zero.

A good cause to celebrate!

version 9.0 (2021-02-01)

  • Upgrades to Nimbus JOSE+JWT 9.x (9.4.1) where the JSON Smart (net.minidev:json-smart) dependency is shaded.
  • Adds new safe JSONObjectUtils.toJSONObject(com.nimbusds.jwt.JWTClaimsSet) method for obtaining a net.minidev.json.JSONObject representation of a JWT claims set.
  • Fixes IDTokenClaimsVerifier to check for azp claim present when multiple ID token aud claim values present (iss #263).
  • Updates to OpenSAML 3.4.6.

Connect2id server 10.4

Before we head into the Christmas holiday we have a small Connect2id server update for you.

New plugin for verifying software statements

The server now comes packaged with a plugin for verifying software statements which may be included to a client registration request to attest selected parameters, such as those that define the client identity. The plugin is highly configurable and can for instance handle the type of software statements used in OpenBanking.

The plugin is based on the registration interceptor SPI and is disabled by default.

Updated plugin for handling OAuth 2.0 client credentials grants

The included plugin for handling client credentials grants can now be configured to include selected client metadata fields in the issued access tokens. This can be useful in cases when the resource servers consuming the access tokens need to obtain additional client identity details besides the client_id.

Caching for selected metrics

The monitoring endpoint returns metrics which include gauges indicating the current number of active sessions, long-lived authorisations and other objects. If you have a backend database where querying the object count is expensive, typically with transactional SQL stores, and there are potentially hundreds of thousands or more objects, you can benefit from the new caching and not worry about polling the metrics too often.

The caching is controlled by the new monitor.entryCountCacheTimeout configuration property, which has a default value of 30 minutes (1800 seconds).


Caching can be entirely turned off, by setting it to zero.


If the database load is still a concern the count readings can also be disabled.


OpenID Connect Federation 1.0 draft 14

Following the 3rd OpenID Connect Federation interop in December 2020 the code was updated for the new draft 14 (not published yet at the time of this writing).

In explicit federation Relying Party (RP) registration the trust_anchor_id will now be returned as top-level entity statement claim about the registered RP, instead of as RP metadata parameter.

Handling of metadata policy was also updated, but isn't fully on par with the upcoming draft yet.

For a complete list of the changes and addressed issue see the notes below.


Standard Connect2id server edition

Apache Tomcat package with Connect2id server 10.4: Connect2id-server.zip

SHA-256: 56c68bcdef80b2c37bd949de3ead6e133da15421de7775232a5e622d9debb6b3

Connect2id server 10.4 WAR package: c2id.war

SHA-256: 07b97dd583f4a3b00e5aa3c2bbc97e0786acface4e40a0e396b610532d6d128d

Multi-tenant edition

Apache Tomcat package with Connect2id server 10.4: Connect2id-server-mt.zip

SHA-256: dbfc3af780a4950d0b111c286d4a5a08a6a2f6b6266752212f044f170c18108d

Connect2id server 10.4 WAR package: c2id-multi-tenant.war

SHA-256: 95d3b67235b2328d5a86173292580647f8fb9d242f02c2fe187d68498acce51a


Contact Connect2id support.

Release notes

10.4 (2020-12-21)


  • Adds a plugin for verifying software statements in OAuth 2.0 client registration requests.

  • Introducing configurable caching for selected metrics which report Connect2id server object count in order to conserve database query resources.

  • Upgrades OpenID Connect Federation 1.0 support to draft 14.


  • /WEB-INF/monitor.properties

    • monitor.entryCountCacheTimeout -- New configuration property, specifies a timeout for caching entry count results, in seconds. Zero disables caching, negative disables readings, causing the gauge to always return -1. The default timeout value is 1800 seconds (30 minutes).

      Gauges with entry count caching:

      • authzSessionStore.numSessions
      • sessionStore.numSessions
      • clientStore.numRegistrations
      • clientStore.numCachedRemoteJWKSets
      • clientStore.numCachedRemoteRequestObjects
      • authzStore.numAuthzCodes
      • authzStore.numIdAccessTokens
      • authzStore.numLongLivedAuthorizations
      • authzStore.numRevocationJournalEntries


  • /federation/clients

    • Upgrades explicit federation Relying Party (RP) registration to draft 14. The trust_anchor_id will now be returned as top-level entity statement claim about the registered RP, instead of as RP metadata parameter.
  • /monitor/v1/metrics

    • Introduces caching to the following gauges which report the number of persisted or cached Connect2id server objects for a given type. Intended to conserve database resources when querying the object count is expensive, for example in MySQL tables with millions of rows. The caching and timeout is controlled by the new monitor.entryCountCacheTimeout configuration property.

      • authzSessionStore.numSessions
      • sessionStore.numSessions
      • clientStore.numRegistrations
      • clientStore.numCachedRemoteJWKSets
      • clientStore.numCachedRemoteRequestObjects
      • authzStore.numAuthzCodes
      • authzStore.numIdAccessTokens
      • authzStore.numLongLivedAuthorizations
      • authzStore.numRevocationJournalEntries


  • Upgrades the Connect2id server SDK to com.nimbusds:c2id-server-sdk:4.24

  • com.nimbusds.openid.connect.provider.spi.reg.FinalMetadataValidator

    • Adds a new "getReceivedMetadata" method to the ValidatorContext that returns the original OAuth 2.0 client / OpenID relying party metadata as received at the client registration endpoint.
  • com.nimbusds.openid.connect.provider.spi.grants.ClientCredentialsGrantHandler

    • Upgrades the included OAuth 2.0 client credentials grant handler plugin, see https://bitbucket.org/connect2id/client-credentials-grant-handler .

      • New op.grantHandler.clientCredentials.simpleHandler.accessToken.includeClientMetadataFields configuration property to specify names of client metadata fields to include in the optional access token data field, empty set if none. To specify a member within a field that is a JSON object member use dot (.) notation.

      • The op.grantHandler.clientCredentials.simpleHandler.enable configuration property receives a default value false (disabled).

      • Lets op.grantHandler.clientCredentials.simpleHandler.accessToken.audienceList also apply to identifier-based access tokens.

      • Makes the /WEB-INF/clientGrantHandler.properties configuration file optional.

  • com.nimbusds.openid.connect.provider.spi.reg.RegistrationInterceptor

    • Allows more than one RegistrationInterceptor SPI implementation to be present, but only at most one can be enabled.

    • New plugin for verifying optional software statements included in OAuth 2.0 client registration requests. Also supports registration requests encoded into a signed JWT and submitted over mutual TLS with a client X.509 certificate, to conform with Open Banking and other profiles. See https://bitbucket.org/connect2id/software-statement-verifier .

Resolved issues

  • Submitted client X.509 certificate must be supplied to the RegistrationInterceptor SPI (issue server/618).

  • Client certificate extraction log messages OP6020 and OP6021 must be assigned to the appropriate Connect2id server endpoint (issue server/617).

  • Improves exception messaging and logging when parsing corrupted string array fields from SQL records (issue server/470).

  • Logs CustomTokenResponseComposer SPI implementation loading under OP6218 (issue server/620).

Dependency changes

  • Upgrades to com.nimbusds:c2id-server-sdk:4.24

  • Upgrades to com.nimbusds:oauth2-oidc-sdk:8.29

  • Updates to com.nimbusds:oauth2-authz-store:16.4

  • Updates to com.nimbusds:oidc-session-store:14.2

  • Upgrades to com.nimbusds:common:2.44

  • Updates to io.dropwizard.metrics:*:4.1.16

  • Updates to com.nimbusds:infinispan-cachestore-sql:4.2.3

  • Updates to com.unboundid:unboundid-ldapsdk:5.1.3

  • Upgrades to com.nimbusds:oauth-client-grant-handler:2.0

  • New com.nimbusds:software-statement-verifier:2.1 dependency

  • Updates to org.bouncycastle:*:1.67

  • Updates to com.thetransactioncompany:cors-filter:2.9.1

Connect2id server 10.3 introduces new plugin interface for handling software statements

This new release of the Connect2id server ships two new features and one bug fix.

SPI for handling software statements

One way of managing and securing client registration is with software statements, a signed JWT embedded into the client metadata which locks selected parameters, for example the client name, logo and other configurations, and further allows the request to be authenticated. Software statements appear in OpenBanking with dynamic client registration, where client application parameters are kept and attested by a central directory.

Previously, to handle such statements or requests secured in some other way, a custom web service had to be layered on top of the clients API.

This new release introduces a plugin interface (SPI) for intercepting incoming HTTP requests, and potentially validating and rewriting them to implement software statements or some other security profile for client registration.

Sample client registration request with an embedded software statement:

POST /clients HTTP/1.1
Content-Type: application/json
Accept: application/json

  "redirect_uris"      : [ "https://client.example.org/cb" ],
  "software_statement" : "eyJhbGciOiJSUzI1NiJ9.

Enabled PKCE methods configuration

An op.authz.allowedPKCE configuration property is added setting the enabled PKCE methods.

To limit the allowed code challenge methods to S256 only:


The allowed PKCE methods will be advertised in the server metadata under code_challenge_methods_supported.

Resolved issues

Fixes a DB schema schema bug affecting 10.x deployments with MySQL 5.7.x. See the release notes for details.


Standard Connect2id server edition

Apache Tomcat package with Connect2id server 10.3: Connect2id-server.zip

SHA-256: a740bc2558becb304e51f171a5a579fa46b6ced54b5b192bd108eed289fd3a4f

Connect2id server 10.3 WAR package: c2id.war

SHA-256: bc3bb2b6424d90d13d342e6a5a77601b62220197ecc93ffb8058bceb75fdf79e

Multi-tenant edition

Apache Tomcat package with Connect2id server 10.3: Connect2id-server-mt.zip

SHA-256: 0c2fe2f57d3cd56ae7f96883f99085adcd3842b21dbae8f05b6e9e8a8de559c6

Connect2id server 10.3 WAR package: c2id-multi-tenant.war

SHA-256: fa8c7a638aa24ad5f0ca1366148de3b40703a33364860b7de29525122ceded96


Contact Connect2id support.

Release notes

10.3 (2020-11-25)


  • /WEB-INF/oidcProvider.properties

    • op.authz.allowedPKCE -- New optional configuration property specifying the allowed PKCE (RFC 7636) code challenge methods which OAuth 2.0 clients may use at the authorisation endpoint, as comma and / or space separated list. The default allowed code challenge methods are "plain" and "S256" (all RFC 7636 methods).

      Authorisation requests which use a code challenge method that isn't allowed by the configuration will be rejected with an invalid_request error.

      The allowed code challenge methods will be advertised in the OpenID provider / OAuth 2.0 authorisation server "code_challenge_methods_supported" metadata field.


  • Upgrades the Connect2id server SDK to com.nimbusds:c2id-server-sdk:4.23

  • com.nimbusds.openid.connect.provider.spi.reg.RegistrationInterceptor

    • New SPI for intercepting and optionally modifying HTTP POST, GET, PUT and DELETE requests at the client registration endpoint. Can be used to process software statements (RFC 7591, section 2.3) and signed (JWT) registration requests (such as those in Open Banking Dynamic Client Registration).

Resolved issues

  • Fixes issue in the MySQL schema for the federation_clients table where MySQL 5.7.x doesn't accept a second TIMESTAMP column with NON NULL declaration. MySQL 8.x is not affected (issue server/614).

Dependency changes

  • Upgrades to com.nimbusds:c2id-server-sdk:4.23

  • Upgrades to com.nimbusds:oauth2-oidc-sdk:8.27

  • Upgrades to com.thetransactioncompany:java-property-utils:1.16

Connect2id server 10.2

The 10.2 release of the Connect2id server brings two security updates and an update to the logout API.

Preventing mix-up attacks on plain OAuth 2.0 clients

The OAuth 2.0 security topics describes the mix-up attack. An OAuth 2.0 client which interacts with two or-more authorisation servers, where the client has used dynamic client registration or one of the servers has been compromised, can become susceptible to the mix-up attack.

The universal countermeasure is to let the authorisation response include the issuer identifier, as an extra iss parameter:

HTTP/1.1 302 Found
Location: https://client.example/cb?

The OAuth client, when receiving an authorisation success or error response, needs to check that the returned iss parameter matches the expected issuer URL of the authorisation server when the request was started. This measure effectively enables clients to detect mix-up attacks and prevent impersonation.

Note that because OpenID relying parties (RPs) receive an ID token, which states the issuer URL of the server, and RPs are required to validate the token iss (along with other claims in the ID token), they are not susceptible to the mix-up attack.

The iss parameter is being standardised in a new spec at the OAuth WG. The spec also defines a new server metadata parameter, authorization_response_iss_parameter_supported, to let clients find out if the iss response parameter is provided and hence they can start checking for it.

  "issuer"                                         : "https://c2id.com",
  "jwks_uri"                                       : "https://c2id.com/jwks.json",
  "authorization_response_iss_parameter_supported" : true

Starting with this release the Connect2id server will include the iss in all authorisation responses.

Tightened URI scheme security

In order to allow callbacks into native clients OAuth 2.0 and OpenID Connect allow clients to be registered with redirection URIs with schemes other than the https scheme.

An article published this week by the security researcher Lauritz Holtmann discusses a class of XSS attacks which may get launched by dynamically registered clients which have set the redirect_uri scheme to javascript, data or vbscript. Firefox was one of the first browsers that started blocking top-level data URIs in 2017, but other and older browsers can still be susceptible to this attack.

To close this loophole the Connect2id server will now prohibit registration of authorisation and post-logout redirection URIs with the schemes javascript, data and vbscript.

The Connect2id server will also block registration of client metadata parameters intended to render links in the browser with URI schemes other than https and http, such as the optional client_uri (client homepage), policy_uri (client privacy policy) and tos_uri (client terms and conditions).

Connect2id server deployments which allow open / dynamic registration are advised to upgrade.

Logout web API update

The logout session web API of the Connect2id server receives an update which fixes a shortcoming in the original design of the API.

A relying party which makes a logout request has the option to specify a post_logout_redirect_uri where the browser should be sent after the logout request is processed. This post-logout redirection URI must be registered in advance, similar to the possible redirect_uris in authorisation requests.


When the end-user is not logged in or their session has expired the original logout API of the Connect2id server will return an invalid_session error to the UI. In cases when the RP has requested a post-logout redirection the UI would not be able to trigger the post-logout redirection, leaving the end-user at the IdP logout page.

The logout API is now updated to no longer return invalid_session errors to the UI, thus allowing a post-logout redirection also in those cases when there is no active session. Note that the post-logout redirection requires an ID token hint to be included in the request, and the Connect2id server will check it to ensure the URI is registered for the RP which received it.


Standard Connect2id server edition

Apache Tomcat package with Connect2id server 10.2: Connect2id-server.zip

SHA-256: 13197322db606ec1a030b7d2a792901fbea0f33987b2503332603440b4089d86

Connect2id server 10.2 WAR package: c2id.war

SHA-256: ed2a5c28636a6d56029529bd77bff2cdef30c0464e3c344f59d03343a5549720

Multi-tenant edition

Apache Tomcat package with Connect2id server 10.2: Connect2id-server-mt.zip

SHA-256: b0c98a1094c1d3b829afa39f2375ce66ef10e37183d9e05d82c30471d94e37da

Connect2id server 10.2 WAR package: c2id-multi-tenant.war

SHA-256: 74e338dc23c3a4f74794f8edd34c98c1855181fd8ecdbb5079ca967ba733914d


Contact Connect2id support.

Release notes

10.2 (2020-11-13)


  • Includes the Connect2id server issuer URL as "iss" parameter in authorisation responses. Intended for OAuth 2.0 clients using more than one authorisation server to prevent a class of attacks called "mix-up" attacks. Clients interacting with a single OAuth 2.0 server and OpenID relying parties which receive an ID token (and accordingly validate the "iss" claim) are not affected. See OAuth 2.0 Authorization Server Issuer Identifier in Authorization Response (draft-meyerzuselhausen-oauth-iss-auth-resp-01) for further details.

  • Tightens the URI scheme policy for OAuth 2.0 client metadata to prevent potential attacks using malicious "javascript", "data" and "vbscript" schemes in old and insufficiently protected web browsers. Deployments which utilise open client registration are advised to upgrade. See the article at https://security.lauritz-holtmann.de/post/sso-security-redirect-uri/ for further details.

  • Updates the logout web API to facilitate post-logout redirections in cases when the end-user session has expired.


  • /WEB-INF/oidcProvider.properties

    • op.policy, op.tos, op.serviceDocs -- If the optional policy, terms of service and service documentation links are specified by absolute URL, the scheme must be either "https" or "http".


  • /.well-known/openid-configuration, /.well-known/oauth-authorization-server

    • Adds the "authorization_response_iss_parameter_supported" metadata parameter (the value is set to true), as specified in OAuth 2.0 Authorization Server Issuer Identifier in Authorization Response (draft-meyerzuselhausen-oauth-iss-auth-resp-01).
  • /authz-sessions/rest/v3/

    • Includes an "iss" (issuer) parameter in OAuth 2.0 authorisation success and error responses, as specified in OAuth 2.0 Authorization Server Issuer Identifier in Authorization Response (draft-meyerzuselhausen-oauth-iss-auth-resp-01). Intended for OAuth 2.0 clients using more than one authorisation server to prevent a class of attacks called "mix-up" attacks. Clients interacting with a single OAuth 2.0 server and OpenID relying parties which receive an ID token (and accordingly validate the "iss" claim) are not affected.
  • /clients

    • Registration of OAuth 2.0 clients and OpenID relying parties with "redirect_uris" or "post_logout_redirect_uris" containing the custom URI schemes "javascript", "data" and "vbscript" is prohibited for security reasons. Native applications can continue registering redirection URIs with custom URI schemes which don't match the prohibited.

    • Registration of OAuth 2.0 clients with "client_uri", "policy_uri" or "tos_uri" with URI schemes other than "https" and "http" is prohibited for security reasons.

    • Registration of OpenID relying parties will no longer permit custom URI schemes for "frontchannel_logout_uri" and "backchannel_logout_uri". The only permitted URI scheme is "https".

  • /logout-sessions/rest/v1/

    • Updates the logout session web API to not return an "invalid_session" error when the submitted end-user session SID (typically stored in a browser cookie at the IdP domain) is invalid or expired. OpenID relying parties (RP) making a logout request with a valid "post_logout_redirect_uri" will thus be able to complete the redirection, regardless of the end-user session state at the IdP.

      Following this change "invalid_session" errors will no longer be returned by the logout session web API.

Resolved issues

  • Prohibits registration of OAuth 2.0 clients and OpenID relying parties with "redirect_uris" or "post_logout_redirect_uris" with the custom URI schemes "javascript", "data" and "vbscript" for security reasons. Also requires browser rendered URIs derived from client and server metadata, such as "client_uri", "policy_uri" and "tos_uri" to have an "https" or "http" URI. See https://security.lauritz-holtmann.de/post/sso-security-redirect-uri/ for more information (issue server/611).

  • Prohibits registration of OpenID relying parties with custom "frontchannel_logout_uri" and "frontchannel_logout_uri" URI schemes, thus making "https" the only allowed URI scheme (issue server/612).

  • Improves INFO logging at the logout session endpoint (issue server/610).

Dependency changes

  • Upgrades to com.nimbusds:oauth2-oidc-sdk:8.26

Connect2id server 10.1 with OpenID Connect federation and Identity Assurance / eKYC updates

The second OpenID Connect Federation 1.0 interop, which took place in September, tested automatic federation clients, which are now fully supported by the Connect2id server. To find out what this new OpenID Connect extension is about and how it enables identity federations to be operated at virtually any scale, in hierarchical and mesh topologies of trust, revisit the Connect2id server 10.0 release announcement.

The second topic of this release is the Identity Assurance / eKYC extension. The Connect2id server will now accept a special case of requests for verified claims, those that involve multiple or different verifications. To simplify the processing of such requests we've been contemplating some changes to the authZ session API, in one of the next Connect2id server releases (feel free to chime in!). We'll continue updating the guide for IdA / eKYC providers with new examples and tips.

The underlying OAuth 2.0 / OpenID Connect SDK (v8.23) was also revised, for a nicer, immutable OO development when dealing with regular as well as verified claims.

For a full description of the new features, changes and bug fixes in Connect2id server 10.1 check the release notes below.


Standard Connect2id server edition

Apache Tomcat package with Connect2id server 10.1: Connect2id-server.zip

SHA-256: cf8f58e3c1525a2aebd399090d09ded28f4f76f48586f3c84f70aa1bdaa7716d

Connect2id server 10.1 WAR package: c2id.war

SHA-256: d2a440e956959d1695dc3009c3b6b024f9291c773657d48a025ebba15e971a43

Multi-tenant edition

Apache Tomcat package with Connect2id server 10.1: Connect2id-server-mt.zip

SHA-256: 333cd88a1b96d49b0c1b651fd43181a35fadec38a72e27bb178234fdc1ff4aa3

Connect2id server 10.1 WAR package: c2id-multi-tenant.war

SHA-256: bf64cfdc26e040737017298faab5b6c3ebaf36253ba87a8bcdff12265cceed0e


Contact Connect2id support.

Release notes

10.1 (2020-10-29)


  • Adds support for OpenID Connect Federation 1.0 (draft 12) automatic clients. Automatic clients don't register explicitly with the Connect2id server, instead they proceed directly to the authorisation endpoint, where they submit a signed request object (JWT) containing additional federation- specific claims, thus letting the request object also serve as an implicit authenticated registration request. The Connect2id server will perform the regular federation trust chain resolution and retrieve the client's metadata from its federation entity statement published at a well-known endpoint. The client registration will expire according to a configured policy - a set lifetime or the trust chain lifetime.

    See https://openid.net/specs/openid-connect-federation-1_0-12.html.

  • Updates OpenID Connect for Identity Assurance 1.0 (draft 11) support to accept "claims" authentication request parameters where the "verified_claims" element is a JSON array. This is intended to enable requests for claims sets with different verification requirements (e.g. different trust frameworks). Previously such requests will result in a invalid_request error at the authorisation endpoint.

    Example "claims" request for two verifications, using the "eidas_ial_substantial" and the "de_aml" trust frameworks:

    "userinfo": {
      "verified_claims": [
          "verification": {
            "trust_framework": {
              "value": "eidas_ial_substantial"
          "claims": {
            "given_name": null,
            "family_name": null
          "verification": {
            "trust_framework": {
              "value": "de_aml"
          "claims": {
            "birthdate": null

    The consent prompt in the authorisation session API will list the requested verified claims across all elements in the "verified_claims" JSON array.

    Note that "claims" -> "verification" will only present the first requested "verification" element if multiple are found. Use the "claims" -> "raw_request" to obtain all verifications. A future version of the Connect2id server will update the consent prompt to simplify handling of verified claims requests with multiple verifications.

    See https://openid.net/specs/openid-connect-4-identity-assurance-1_0-11.html, section 6.3.3.

  • Connect2id server deployments with an AWS DynamoDB backend can be configured to include a SHA-256 based message authentication code (HMAC) in each stored item to guarantee its integrity and authenticity while stored in the database.


  • /WEB-INF/oidcProvider.properties

    • op.federation.clientRegistrationTypes -- The configuration property for the supported OpenID Connect Federation 1.0 client registration types now allows for automatic as well as explicit registration.

    • op.federation.autoClientAuthMethods.ar -- New configuration property specifying the supported methods for authenticating implicit registration requests of OpenID Connect Federation 1.0 automatic clients at the OAuth 2.0 authorisation endpoint. The only currently supported method is "request_object".

    • op.federation.autoClientLifetime -- New configuration property for the lifetime of registered OpenID Connect Federation 1.0 automatic clients, in seconds. If zero or negative the lifetime will be determined by the trust chain expiration time. When explicitly set must not be shorter than 5 minutes (300 seconds) to allow sufficient time for the completion of a single OAuth 2.0 flow with an authorisation, token and UserInfo request by the registered relying party. The default lifetime is one hour (3600 seconds).

  • /WEB-INF/infinispan-*-dynamodb.xml

    • Updates the DynamoDB store schema to v1.8 and adds the option to secure the integrity and authenticity of the stored DynamoDB items with a SHA-256 based Message Authentication Code (HMAC), appended to each item in a "_hmac#256" binary attribute. If a retrieved DynamoDB item is missing the "_hmac#256" attribute or its verification fails the Connect2id server will produce an HTTP 500 Internal Server Error, log the error with a "DS0131" code and increment the ".dynamoDB.invalidItemHmacCounter" metric.

      To enable this HMAC protection the Connect2id server must be configured with a secret 256 bit key (as BASE-64 encoded string) in the "dynamoDB.hmacSHA256Key" Java system property.

      The HMAC protection must be enabled for newly provisioned or empty DynamoDB tables. Enabling the protection for DynamoDB tables with prior existing items will cause HMAC validation errors on their retrieval.

  • /WEB-INF/infinispan-stateless-dynamodb.xml

    • DynamoDB consistent reads for "sessionStore.sessionMap" can be enabled by setting the "dynamodb.consistentReads.sessionStore.sessionMap" Java system property to true.


  • /authz-sessions/rest/v3/

    • The consent prompt "claims" parameter adds support for verified claims requests (OpenID Connect Identity Assurance 1.0) with multiple verifications.

      The "claims" -> "new" -> "essential", "voluntary" arrays will list the requested verified claims (prefixed with "verified:") across all "verified_claims" elements (if multiple are found).

      The "claims" -> "verification" -> "id_token", "userinfo" objects will include the first found verification element (if multiple are found), the full list of verification objects can be obtained by parsing the "claims" -> "raw_request" parameter (requires op.authz.includeRawClaimsRequestInPrompt=false).

  • /monitor/v1/metrics

    • Adds new ".dynamoDB.invalidItemHmacCounter" metric of type counter for Connect2id server deployments with a DynamoDB database. Counts the number of retrieved DynamoDB items which failed the HMAC SHA-256 check (if enabled).


  • PasswordGrantHandler, JWTGrantHandler, SAML2GrantHandler

    • Consented claims which name is prefixed with "id_token:" will be included in the ID token instead of via the default method, the UserInfo endpoint. This feature is adopted from the authorisation session web API.
  • Included OpenID Connect HTTP claims source

    • Updates the included AdvancedClaimsSource SPI implementation for sourcing OpenID claims from an HTTP endpoint to version 2.1 (com.nimbusds:oidc-claims-source-http:2.1). The JSON object representing the request will now include a "claims_transport" parameter hinting how the requested claims are going to be transported to the relying party: "userinfo" for the UserInfo endpoint, "id_token" for the ID token, omitted if not applicable (for claims requested by an internal plugin, such as an access token codec).

Resolved issues

  • OpenID claims requests with JSON array of verified_claims must not fail (issue server/605).

  • Fixes NPE in OpenID Connect Federation 1.0 client registration error processing logic (issue server/585).

  • Front-channel logout requests must not include the issuer identifier (iss) as query parameter when a session identifier (sid) isn't included (issue server/595).

  • Updates the OAuth 2.0 authorisation endpoint to reject signed (JWS) request objects (JARs) where the optional JWT "sub" (subject) claim is set to the client_id value, see the latest cross-JWT confusion security recommendation in https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-29#section-10.8 (issue server/588).

  • Fixes the reported "request" (JAR) parameter name in illegal_request error messages from the OAuth 2.0 authorisation endpoint (issue server/589).

  • Ignore unknown key types in a JWK set, when parsing a client JWK set and in other cases (issue nimbus-jose-jwt/377).

  • Logs at INFO level the enabled / disabled status of every loaded claims source at Connect2id server startup under OP7107 (issue server/600).

  • Logs at TRACE level the decoded self-contained access token authorisation under AS0544 (issue authz-server/178).

  • HTTP POST and PUT requests to the client registration endpoint where the entity body exceeds the hard-wired character limit must return a HTTP 400 Bad Request, not HTTP 500 Internal Server Error. Raises the limit from 15 thousand to 20 thousand characters (issue server/579).

Dependency changes

  • Upgrades to com.nimbusds:oauth2-oidc-sdk:8.23.1

  • Updates to com.nimbusds:nimbus-jose-jwt:8.20.1

  • Updates to com.nimbusds:oauth2-authz-store:16.3

  • Updates to com.nimbusds:oidc-claims-source-http:2.1

  • Updates to BouncyCastle 1.66

  • Updates to Infinispan 9.4.20

  • Upgrades to com.nimbusds:infinispan-cachestore-dynamodb:3.7.2

  • Updates to com.unboundid:unboundid-ldapsdk:5.1.1

  • Updates to com.amazonaws:aws-java-sdk-bundle:1.11.880