Issuer aliases in Connect2id server 12.3

2021-09-20

The September release of the Connect2id server brings support for issuer aliases. An issuer alias URL can be configured to migrate a Connect2id server deployment seamlessly and over time from one issuer identifier URL to another. Issuer aliases can also be used to identify an OpenID provider / OAuth 2.0 authorisation server by multiple URLs.

Check the new guide for how to configure and switch between issuer aliases in a Connect2id server deployment.

Download

Standard Connect2id server edition

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

SHA-256: 6bd77fc1d3ba1a0222c222ca8b194ec2c37164b6585c96c871725bc4279c7509

Connect2id server 12.3 WAR package: c2id.war

SHA-256: 2050dea95db72dfb57ab4f99fef4356068f262d19698aa1c196ba398f01bfbd6

Multi-tenant edition

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

SHA-256: 44c87b33cef26e754d1702b99651fd594dd5b1ec3d70c94fb0f8919136aabf91

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

SHA-256: d12ba4fa77de3cf836e43a5f6e646a7dfe8b9aeed4e8271c4504a3632e612ec5

Questions?

Contact Connect2id support.

Release notes

12.3 (2021-09-17)

Summary

  • Supports issuer URL aliases. An issuer alias URL can be configured to migrate
    a Connect2id server deployment seamlessly and over time from one issuer identifier URL (op.issuer) to another. Issuer aliases can also be used when an OpenID provider / OAuth 2.0 authorisation server is known by multiple URLs.

    The allowed issuer aliases, if any, are configured in a new optional op.issuerAliases.* property.

    A Connect2id server endpoint or API will process a request under an issuer alias when the HTTP request header "Issuer" is present and set to a value matching a configured alias. If no "Issuer" header is specified the default issuer configured in op.issuer will be assumed. The default op.issuer will also be assumed when the "Issuer" header is explicitly set to it. If the "Issuer" header is set to an issuer URL that isn't configured the Connect2id server will return an HTTP 400 error with a message.

    The "Issuer" header must be set by the reverse HTTP proxy or similar trusted internal infrastructure. It must not be settable by client applications. Connect2id server deployments must scrub the incoming client application HTTP requests from any "Issuer" headers.

    Issuer aliases are supported in the regular as well as the multi-tenant Connect2id server edition.

Configuration

  • /WEB-INF/oidcProvider.properties

    • op.issuer.aliases.* -- New optional configuration property for setting one or more issuer alias URLs of the OpenID provider / OAuth 2.0 authorisation server. Can be used to migrate from one issuer URL (op.issuer) to another, or to operate an OpenID provider / OAuth 2.0 authorisation server that is known by multiple URLs. Blank if none.

Web API

  • The standard OAuth 2.0 / OpenID Connect endpoints and Connect2id server specific web APIs will process a request under a configured issuer alias (op.issuerAliases.*) when the HTTP request includes an "Issuer" header set to the issuer alias URL. The header value must match the configured issuer alias URL exactly. If the "Issuer" header is set to an issuer URL that isn't configured the Connect2id server will return an HTTP 400 "Bad Request" error with an appropriate message.

Resolved issues

  • Updates log message OP6205 for reporting internal token handler errors to include the client ID, authentication method and grant (issue server/693).

Dependency changes

  • Updates to com.nimbusds:tenant-manager:6.0.2

  • Updates to com.nimbusds:tenant-registry:6.0

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

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

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

  • Updates to org.cryptomator:siv-mode:1.4.3

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

  • Updates to com.google.code.gson:gson:2.8.8

DPoP tokens with the OpenID Connect developer client

2021-09-06

Our open source web client for testing OpenID Connect compliant providers received an update to handle DPoP tokens.

OpenID Connect client

DPoP is a new type of OAuth 2.0 token, designed primarily for Single Page Applications (SPAs) and with higher-grade security than the common Bearer tokens. The extra DPoP security makes the token "sender-constrained", by binding it to a private RSA or EC key that belongs to the client. A DPoP token that is leaked, by accident or through some malicious action, cannot be used on its own (as opposed to Bearer tokens). For a client to use a DPoP token at the intended endpoint it must also possess the private binding key and this key can be generated and stored via the SubtleCrypto API in a way that prevents its extraction from the browser.

Note, the DPoP token is not a security cure for buggy or vulnerable JavaScript code in a SPA! If the SPA is taken over in a XSS attack the malicious code may perform all the necessary operations to impersonate the legitimate user without exfiltrating the private key.

You can test DPoP in our online demo against the most recent Connect2id server release (v12.2):

Client URL https://demo.c2id.com/oidc-client/

To trigger a request for a DPoP token click on the Options "Show" button, then select a JWS algorithm for the DPoP proof, a signed JWT used to Demonstrate Proof-of-Possession (DPoP) of the key at the OAuth 2.0 server. You can select RS256 or any other JWS algorithm that is supported by the server.

DPoP request

When done click on "Authenticate with OpenID Connect" and follow the flow through the login and consent screens on the server.

The type of the returned access token is shown in the standard token_type parameter:

DPoP response

If the server issued a refresh token, and the OAuth 2.0 client / OpenID relying party is public (as an SPA technically is, because it has no authenticating client credentials), the refresh token will also be DPoP bound, just like the access token, to prevent its use in case of a leak.

This web client is built with the open source OAuth 2.0 / OpenID Connect SDK, which implements all standards in the OAuth 2.0 and OpenID Connect space, and the majority of drafts in development. Feel free to fork it or contribute if you have ideas!

To join the DPoP discussion check out the OAuth WG mailing list.

DPoP access tokens in Connect2id server 12.2

2021-08-26

Connect2id server 12.2 introduces support for DPoP tokens and configuring longer RSA keys. It also addresses several issues, described in the release notes.

DPoP access tokens

Single-page applications (SPA) can now request the issue of DPoP access tokens from the Connect2id server. This is a new kind of token, with stronger security properties than the default Bearer access tokens in OAuth 2.0. The DPoP token comes with a protection against unauthorised use in case it suffers an accidental or malicious leak. This is achieved by binding the token to a private key held by the client. To prevent a leak of the key itself the client should store it behind an API that renders its private parameters inaccessible to application code. The SubtleCrypto (WebCrypto) API has this option, its generateKey() method for RSA an EC keys when called with extractable=false will prevent JavaScript application code from exporting the private key parameters from the browser.

DPoP is an alternative to the conceptually similar client certificate bound tokens (RFC 8705), which ultimately are also bound to a private key. The difference is that in DPoP the binding is conveyed by means of a JWT instead of a client X.509 certificate.

Token type Binding Spec
Bearer none RFC 6750
Bearer with client certificate binding via client X.509 certificate RFC 8705
DPoP via signed JWT draft

The security properties of the client certificate binding are stronger because it involves the underlying secure transport layer (TLS), which made it the recommended method for applications, for example in the FAPI (financial-grade) OAuth 2.0 security profile. Browsers however don't provide a JavaScript API to enable application code to deal client certificates and mutual TLS, and to work around this the DPoP binding was invented.

The current DPoP spec is draft-ietf-oauth-dpop-03. It is now considered mature for production use and an official RFC should appear in the coming months.

How can an SPA request a DPoP token?

  1. At the start of a new session the SPA generates a new RSA or EC key pair, with disabled extraction (extractable=false) so the private key parameters cannot be exported from the browser.

  2. To request a DPoP access token the SPA generates a one-time-use JWT signed with the private key. The function of this JWT is to demonstrate possession of the key (hence the PoP acronym). Its header includes the public parameters of the signing key in JWK format. The claims include a unique JWT identifier (jti), the JWT issue time (iat) and the HTTP method and URI of the token endpoint (htm and htu).

    Example DPoP proof JWT header:

    {
 "typ" : "dpop+jwt",
 "alg" : "ES256",
 "jwk" : { "kty" : "EC",
           "crv" : "P-256",
           "x"   : "l8tFrhx-34tV3hRICRDY9zCkDlpBhF42UQUfWVAWBFs",
           "y"   : "9VE4jf_Ok_o64zbTTlcuNJajHmt6v9TDVrU0CdvGRDA"
 }
}

    Example DPoP proof JWT claims:

    {
 "jti" : "f352c2fa-2d06-47b9-8347-8cda8a70a17d",
 "htm" : "POST",
 "htu" : "https://c2id.com/token",
 "iat" : 1562262616
}

  3. The SPA makes the usual token request to the Connect2id server, but to trigger issue of a DPoP access token the proof JWT must be included in a HTTP request header called DPoP.

    POST /token HTTP/1.1
Host: c2id.com
Content-Type: application/x-www-form-urlencoded;charset=UTF-8
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2IiwiandrIjp7...

grant_type=authorization_code
&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
&code_verifier=bEaL42izcC-o-xBk0K2vuJ6U-y1p9r_wW2dFWIWgjz-

  4. If the DPoP proof is valid and signed with a supported JWS algorithms (the Connect2id server supports all standard RSxxx, PSxxx and ESxxx algorithms) the token response will appear in the usual format, but with the token type set to DPoP.

    HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{
 "access_token"  : "tai1eeJ0eeNgiech.aing6aiJoopohsoh",
 "token_type"    : "DPoP",
 "expires_in"    : 600,
 "refresh_token" : "Ci8Fieshaikeiwaih8Tee5ZuaP5Iepho"
}

How can an SPA access a protected resource with a DPoP token?

To access a protected resource with a DPoP token the client needs to generate a new DPoP proof, with one additional string claim - ath, set to the BASE64URL-encoded SHA-256 hash of the access token value. The htm (HTTP method) and htu (HTTP URI) claims must match those of the resource.

The UserInfo endpoint of the Connect2id server was updated to accept DPoP access tokens. The next section has pointers how to support DPoP tokens at a resource server.

Example DPoP proof JWT claims, for an HTTP GET to some protected resource at https://api.example.com/accounts/123 and with the access token hash in ath:

{
 "jti" : "a6716edf-eb6a-4649-8f6d-ac0325d26738",
 "htm" : "GET",
 "htu" : "https://api.example.com/accounts/123",
 "iat" : 1562262716,
 "ath" : "fUHyO2r2Z3DZ53EsNrWBb0xWXoaNy59IiKCAqksmQEo"
}

The token is passed in a standard Authorization header, but instead of Bearer we have the token scheme set to DPoP:

GET /accounts/123 HTTP/1.1
Host: api.example.com
Authorization: DPoP tai1eeJ0eeNgiech.aing6aiJoopohsoh
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2IiwiandrIjp7...

If the resource server finds the DPoP proof or the token to be invalid or expired it will respond with a standard 401 Unauthorized and describe the error in the WWW-Authenticate header.

Example:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: DPoP error="invalid_token", error_description="Invalid / expired DPoP token", algs="RS256 PS256 ES256"

The algs parameter is optional, but very useful as it allows the client to find out which JWS algorithms for signing the DPoP proofs the resource server is able to handle.

How to support DPoP access tokens in a resource server?

The validation of DPoP tokens is described in the spec and has five steps:

  1. Verify the received access token in the usual way. For self-contained (JWT-encoded) tokens this means a local inspection by checking the JWT signature and claims; for an identifier-based token a call to the introspection endpoint of the Connect2id server.

  2. Check if the token authorisation has a cnf.jkt (confirmation of JWK thumbprint) parameter. If it does, then this is a DPoP token, so proceed further.

  3. Make sure the HTTP request includes a DPoP header and validate the proof JWT in it according to the described procedure.

  4. Compute the SHA-256 thumbprint of the public JWK found in the DPoP proof JWT and make sure it matches the JWK thumbprint (cnf.jkt) which the Connect2id server computed at the token endpoint when it minted the DPoP token. If the two thumbprints match this means we

  5. Finally, compute the SHA-256 hash of the access token and make sure it matches the ath claim of the DPoP proof JWT.

Resource servers may implement an additional check against DPoP proof replay, by recording the proof jti (JWT ID) and making sure it doesn't appear again within the time window determined by the acceptable iat age of the proofs.

The Java open source OAuth 2.0 SDK includes a DPoP proof verifier to help resource servers with this task.

How to refresh a DPoP token?

If the Connect2id server issued a refresh token the client must generate a DPoP proof whenever the refresh token is used.

POST /token HTTP/1.1
Host: c2id.com
Content-Type: application/x-www-form-urlencoded;charset=UTF-8
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2IiwiandrIjp7...

grant_type=refresh_token
&refresh_token=Ci8Fieshaikeiwaih8Tee5ZuaP5Iepho

3072 and 4096 bit RSA keys

The Connect2id server can now be configured with longer RSA keys for signing the issued tokens and receiving encrypted request objects. 2048 bits remains the default length of the generated RSA keys when using the provided jwkset-gen tool.

Download

Standard Connect2id server edition

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

SHA-256: 33b49db86b129a6d92f9ae9fe5cb9562e257e9f7b87f4c3bffa5e4b8c439ccdd

Connect2id server 12.2 WAR package: c2id.war

SHA-256: a85433faf9802b954b24c0251b899af6f8a9ca9a0ec4f8b94f2e091f9185b7cf

Multi-tenant edition

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

SHA-256: a2cf8a27a6d3fbbc802203301273438104bf3c23404ae7efa3ebec41cc98974d

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

SHA-256: 688417f2dde16deb5f7e1f388d2d02060e6f4e8294b8d3633e731deca58864ac

Questions?

Contact Connect2id support.

Release notes

12.2 (2021-08-26)

Summary

  • Supports issue of access tokens of type DPoP, where the token is bound to a private RSA or EC key generated and held by the OAuth 2.0 client, potentially in secure storage preventing the key's extraction. Use of the DPoP token at a resource server requires proof of possession of the private key, preventing the use of an accidentally or maliciously leaked token by an unauthorised party. The original Bearer tokens in OAuth 2.0 offer no such protection to constrain their use.

    DPoP is intended primarily for browser based applications (also commonly called single page applications, or SPAs) where the alternative standard method to constrain a token, by binding it to a client X.509 certificate (RFC 8705), is not suitable, due to the browsers' poor support for dealing with client certificates and mutual TLS in JS application code.

    SPAs should use the WebCrypto browser API to generate the necessary private keys (with disabled extraction) for signing the DPoP proofs and actual signing.

    The Connect2id server accepts the following JWS algorithms for the signed DPoP proof JWTs: RS256, RS384, RS512, PS256, PS384, PS512, ES256, ES256K, ES384 and ES512.

    The Connect2id server will reject DPoP proof JWTs with an "iat" (issued-at time) that is more than 30 seconds behind or ahead of the current system time. Proof JWTs with a repeated "jti" (JWT ID) will also be rejected to prevent replay.

    See OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (draft-ietf-oauth-dpop-03).

  • The Connect2id server can now be configured with longer RSA signing and encryption keys, with lengths of 3072 and 4096 bits. The 2048 RSA key length remains the recommended for now and also the default for in provided jwkset-gen.jar tool for generating server JWK sets (the latest tool version is 1.22).

Configuration

  • /WEB-INF/jwkSet.json

    • Supports RSA signing and encryption keys of lengths 3072 and 4096 bits, in addition to 2048-bit RSA keys.

Web API

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

    • dpop_signing_alg_values_supported -- New metadata field, lists the accepted JWS algorithms for the DPoP proof JWTs: RS256, RS384, RS512, PS256, PS384, PS512, ES256, ES256K, ES384 and ES512.

  • /token

    • Supports issue of access tokens of type DPoP for the following OAuth 2.0 grants:

      • authorisation code
      • refresh token
      • client credentials
      • resource owner password credentials

    • Supports issue of DPoP bound refresh tokens for public OAuth 2.0 clients.

  • /token/introspect

    • Supports introspection of access tokens of type DPoP. Introspection success responses for a DPoP token will have the "token_type" member set to "DPoP" and will include a "cnf.jkt" member set to the BASE64URL encoded SHA-256 thumbprint of the JWK used to sign the DPoP proof JWT.

  • /userinfo

    • Supports access tokens of type DPoP. Those must be included in the "Authorization" HTTP request header using the "DPoP" scheme.

  • /monitor/v1/metrics

    • Adds new "dPoP.numCachedJTIs" metric of type gauge showing the number of locally cached DPoP proof JWT ID (jti) entries intended to ensure the single use of received DPoP proofs at the token and UserInfo endpoints.

SPI

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

    • com.nimbusds.openid.connect.provider.spi.tokens.AccessTokenAuthorization

      • Adds default getJWKThumbprintConfirmation method to represent a DPoP JWK SHA-256 thumbprint confirmation.

    • com.nimbusds.openid.connect.provider.spi.tokens.MutableAccessTokenAuthorization

      • Implements AccessTokenAuthorization.getJWKThumbprintConfirmation

      • Adds withJWKThumbprintConfirmation setter method.

    • com.nimbusds.openid.connect.provider.spi.tokens.BaseSelfContainedAccessTokenClaimsCodec

      • Updates the base abstract codec for JWT-encoded access tokens to support the "cnf.jkt" claim for DPoP.

    • com.nimbusds.openid.connect.provider.spi.tokens.introspection.BaseTokenIntrospectionResponseComposer

      • Updates the base abstract composer for customer token introspection responses support the "cnf.jkt" member for DPoP.

Resolved issues

  • Logs invalid refresh token (AS0270), refresh token request client_id - encoded client mismatch (AS0274) and refresh token not permitted (AS0275) events (issue authz-store/188).

  • Improves the efficiency when loading issuer lookup cache entries in the tenant registry (issue/tenant-registry/5).

  • Fixes a bug in AuthorizationRequest.Builder(AuthorizationRequest) that prevented copy of OpenID authentication request parameters, which can affect modification of requests in AuthorizationRequestValidator and PARValidator SPI implementations (issue oidc-sdk/367).

  • Refactors and extends handling of corrupted JSON in long_lived_authorizations items in a AWS DynamoDB table for get, put-if-absent, replace and remove operations to prevent an internal server error (HTTP 500) and clean up the detected corrupted items where feasible (issues authz-store/186, 187).

Dependency changes

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

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

  • Upgrades to com.nimbusds:nimbus-jose-jwt:9.12.1

  • Upgrades to com.nimbusds:c2id-server-jwkset:1.22

  • Upgrades to com.nimbusds:oauth2-authz-store:17.4.1

  • Updates to com.nimbusds:tenant-registry:5.3.4

Connect2id server 11.6.4

2021-07-31

This is a maintenance update of Connect2id server 11.x, addressing two minor issues and updating dependencies under the hood. Similar updates will appear in the upcoming 12.2 in August.

Check the release notes for further information.

Download

Standard Connect2id server edition

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

SHA-256: 2b9c72f4059e5296aea952cd6ca62256856d314e612317ff306901a1198bf4fd

Connect2id server 11.6.4 WAR package: c2id.war

SHA-256: 201cb2836dd8651f4cf7b958adcff7864a3ff5344ddb45238b7ca8d0d02d176c

Multi-tenant edition

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

SHA-256: 17501539eb7074bdfc5fb3f806be17dbc4dd2b190dba8eef7d6fd148f258009a

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

SHA-256: d0f5b8bdf29213b1ad90c98fc54a4895e54dde41c02b06f00fc8f651dda2bb30

Questions?

Contact Connect2id support.

Release notes

11.6.4 (2021-07-31)

Resolved issues

  • Fixes a bug in AuthorizationRequest.Builder(AuthorizationRequest) that prevented copy of OpenID authentication request parameters, which can affect modification of requests in AuthorizationRequestValidator and PARValidator SPI implementations (issue oidc-sdk/367).

  • Refactors and extends handling of corrupted JSON in long_lived_authorizations items in a AWS DynamoDB table for get, put-if-absent, replace and remove operations to prevent an internal server error (HTTP 500) and clean up the detected corrupted items where feasible (issues authz-store/186, 187).

Dependency changes

  • Updates to com.nimbusds:oauth2-oidc-sdk:9.10.1

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

  • Updates to com.nimbusds:nimbus-jwkset-loader:5.1

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

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

  • Updates to com.nimbusds:common:2.45.4

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

  • Updates to net.minidev:json-smart:2.4.7

  • Updates to com.thetransactioncompany:pretty-json:1.4.3

  • Updates to org.apache.commons:commons-lang3:3.12.0

  • Updates to com.google.crypto.tink:tink:1.6.1

  • Updates to Infinispan 9.4.23.Final.

  • Updates to org.mariadb.jdbc:mariadb-java-client:2.7.3

  • Updates to org.postgresql:postgresql:42.2.23

  • Updates to io.prometheus:simpleclient:0.11.0

  • Updates to io.prometheus:simpleclient_servlet:0.11.0

  • Updates to io.prometheus:simpleclient_dropwizard:0.11.0

  • Updates to Log4j 2.14.1.

  • Adds com.google.code.gson:gson:2.8.7

Connect2id server 12.1

2021-07-05

The Connect2id server receives a maintenance update this week which also ships a new configuration setting to include a jti (JWT ID) claim in the issued ID tokens. This extra claim can be used to uniquely identify the token, be it for audit or other purposes.

To have the jti claim included in ID tokens:

op.idToken.includeJWTID=true

This release fixes several issues and is recommended for v12.0 deployments.

You can find more information in the release notes.

Download

Standard Connect2id server edition

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

SHA-256: be053c6974e9f76029223b7eaafb7209e48feeb5c9635db68ccb3f73229a3bf1

Connect2id server 12.1 WAR package: c2id.war

SHA-256: 39183858459e1ddbdb511e5383670f0d8a4fb6f09b10bf614e14327df26302a5

Multi-tenant edition

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

SHA-256: d124cf2afd85970399db023e40c959b6e18f4ae72270750f5ed018ba12e0d1bb

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

SHA-256: c45f9c2b83c71b2ef6b172f2645c1afedd15f8855a1aff2e5a28acb7992acae2

Questions?

Contact Connect2id support.

Release notes

12.1 (2021-07-05)

Configuration

  • /WEB-INF/oidcProvider.properties

    • op.idToken.includeJWTID -- New configuration property to enable / disable inclusion of a JWT ID claim ("jti") in issued ID tokens. Disabled by default.

Resolved issues

  • Fixes JSON encoding issue that affected serialisation of the ~/7E character into objects and for persistence since v11.3 (issue common/62).

  • Fixes a bug that prevented completion of plain OAuth 2.0 authorisation requests with prompt=none and resulted in a HTTP 500 server error. OpenID authentication requests were not affected (issue server/681).

  • Fixes the label for the OP6520 log event at the token introspection endpoint (issue server/687).

Dependency changes

  • Updates to com.nimbusds:oauth2-oidc-sdk:9.9.1

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

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

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

  • Updates to com.nimbusds:common:2.45.4

  • Updates to com.thetransactioncompany:pretty-json:1.4.3

  • Adds com.google.code.gson:gson:2.8.7