Connect2id server 7.16 with token introspection update


This is a mini update to the Connect2id server which updates the token introspection endpoint to include the optional expiration ("exp") parameter in the response for identifier-based access tokens.

This update also fixes two issues. See the release notes below for more information.


To download a ZIP package of Connect2id server 7.16:

SHA-256: b85b9fea360c38b2287c5f44559c9cc3092aa6bad6eec013504f824107659486

As WAR package only:

SHA-256: d3db91263ad1773fa475f1003ed3f53144629fb0983c3e0de1fea8396930a2d5


Contact Connect2id support.

Release notes

7.16 (2019-09-09)


  • /token/introspect -- Includes the optional expiration (exp) parameter in introspection responses for identifier-based access tokens. See OAuth 2.0 Token Introspection (RFC 7662), section 2.2.

Resolved issues

  • Fixes a bug which resulted in a HTTP 500 error when reading an OAuth 2.0 client registration with an empty JWK set ("jwks") from DynamoDB (issue server/480).

  • Fixes a bug which affected setting of the "exp" and potentially other JWT claims in calls to the AccessTokenIssueEventListener SPI (issue authz-store/164).

Dependency changes

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

Connect2id server 7.15 has new FAPI features


FAPI is a collection of OAuth 2.0 security profiles which were originally intended for fintech applications but can also be employed in other areas where you need strongly secured identity and access tokens. This 7.15 release of the Connect2id server brings several updates for providers that need to be FAPI compliant or want to maintain the highest possible security standard for OAuth and OpenID Connect.

X.509 certificates in server JWKs

An X.509 certificate chain included in a server RSA or EC key (as x5c JWK parameter) will now be exposed in the published public key at the jwks.json endpoint and in the x5c header parameter of JWTs signed with it (ID tokens, self-contained access tokens, etc).

The X.509 certificate chain allows OAuth 2.0 clients to perform PKIX validation of the published key and hence tokens signed with it. Note that the Connect2id server will not perform PKIX validation on a configured JWK if the key includes a certificate chain. Including an "x5c" header in a JWT can also easily multiply its size.

New configuration to make PKCE required for all OAuth 2.0 clients

PKCE is an OAuth 2.0 security enhancement that binds an issued authorisation code to the original authorisation request. It was initially meant to protect public clients that lack a credential to authenticate at the token endpoint from code interception attacks, but can benefit confidential clients as well.

FAPI has therefore made the use of PKCE a requirement. Unfortunately PKCE didn't specify a standard client registration parameter to allow this to be configured individually per OAuth 2.0 client. So we created a new global server configuration op.authz.requiredPKCE which, if set, lists the required code challenge methods (S256, plain) that all clients must use.

Check our PKCE guide for clients if you have a Java application.

The UserInfo endpoint no longer accepts access tokens in the URI query

Passing an access token in the URI query is a horrible practice as it may result in the token leaking through web server logs. To discourage clients from this the UserInfo endpoint of the Connect2id server will no longer accept tokens in the access_token query parameter.

Insecure submission of a bearer token in the URI query:

GET /userinfo?access_token=Toasu1haw8ithop7 HTTP/1.1

The HTTP response will return a helpful error message explaining why the request was rejected:

HTTP/1.1 400 Bad Request
Content-Type: application/json

  "error"             : "invalid_request",
  "error_description" : "Invalid request: Access token disallowed in URI query"

Clients should instead pass the token in a Authorization header or in a access_token form-encoded body parameter.

If for some reason clients cannot transport the access token in the "Authorization" request header field or the HTTP request entity-body, the URI query method can be allowed with a new op.userinfo.allowAccessTokenInURIQuery configuration:

op.userinfo.allowAccessTokenInURIQuery = true

The Userinfo endpoint is now FAPI compliant

The UserInfo endpoint is now FAPI compliant, by normally disallowing tokens in the URI query and by also supporting the X-FAPI-Interaction-ID header. The header is intended to aid logging, auditing and support calls, by giving the resource request and the resulting response (success or error) a common unique identifier. If the client sets the header in the outgoing HTTP request the Connect2id server will echo it in the resulting HTTP response. The value should be an UUID.

GET /userinfo HTTP/1.1
Authorization: Bearer Toasu1haw8ithop7
X-FAPI-Interaction-ID: 1ebc5b42-81cd-4a43-a668-c7383bfd61df

If the request header isn't set the Connect2id server will generate an UUID for the response.

New metrics gauge shows Connect2id server version

The Connect2id server version can now be found out from the metrics endpoint, by looking up the server.version gauge.

HTTP/1.1 200 Success
Cache-Control: must-revalidate,no-cache,no-store
Content-Type: application/json

  "version" : "3.0.0",
  "gauges"  : { "server.version" : { "value": "7.15" },

Bug fixes

The new release also fixes several issues, details in the notes below.


To download a ZIP package of Connect2id server 7.15:

SHA-256: 381366fdedc5524d20ba1b5d4f243a1e09e72c1558af8f5cfe07e441d7327853

As WAR package only:

SHA-256: 617a31748d6a66b822d05ebaed49f6e23597082019fc2b48f44596eb33c9787e


Contact Connect2id support.

Release notes

7.15 (2019-08-26)


  • /WEB-INF/jwkSet.json

    • Public RSA and EC JSON Web Keys (JWK) that specify an X.509 certificate chain ("x5c" parameter, see RFC 7517, section 4.7) will be published at the /jwks.json endpoint with the certificate chain included. Issued ID tokens and self-contained (JWT-encoded) access tokens that are signed with such a key will also include the certificate chain as the "x5c" JWT header parameter (see RFC 7515, section 4.1.6).

      The X.509 certificate chain allows OAuth 2.0 clients to perform PKIX validation of the published keys and the issued tokens. Note that the Connect2id server will not validate the certificate chains of configured server JWKs.

  • /WEB-INF/

    • Adds new "op.authz.requiredPKCE" configuration property listing the required PKCE (RFC 7636) code challenge methods which OAuth 2.0 clients must use at the authorisation endpoint. The values are specified as a comma and / or space separated code challenge method names. If empty or not specified PKCE is not required. The default value is not required.

    • Adds new "op.userinfo.allowAccessTokenInURIQuery" configuration property for the UserInfo endpoint to allow access tokens submitted via the access_token URI query parameter. The default policy (false) now is to reject access tokens received via the URI query parameter in order to prevent potential token leakage via web server access logs. The URI query method should not be allowed unless it is impossible to transport the access token in the "Authorization" request header field or the HTTP request entity-body. See RFC 6750, section 2.3.


  • /userinfo

    • Makes the UserInfo endpoint FAPI profile compliant by logging and echoing the x-fapi-interaction-id HTTP request header. If the header is not set by the client the Connect2id server will generate an UUID value for it and return it in the UserInfo HTTP response.
  • /monitor/v1/metrics

    • Adds new "server.version" gauge of type string to indicate the Connect2id server version, e.g. "7.15".

Resolved issues

  • Skips validation of OpenID authentication request specific parameters, such as "claims", when processing a plain OAuth 2.0 request. Fixes an authorisation session serialisation bug that affected processing of plain OAuth 2.0 requests with custom parameters (issue server/479).

  • Fixes a concurrency issue in the session store introduced in v7.12.1 which may result in a deleted subject session after the session is read. Applies to stateless cluster deployments only (DynamoDB, Redis + MySQL / PostgreSQL) (issue session store/81).

  • Logs the exception message and PEM string when parsing an invalid client X.509 certificate. Fixes logging of a missing client certificate when the Connect2id server is behind an Apache HTTPd reverse proxy (issue server/475).

  • Logs subject session removal events under SS0213 (issue session store/81).

Dependency changes

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

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

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

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

Connect2id server 7.14 supports encrypted request objects


We are delighted to announce support for encrypted request objects (JARs) in Connect2id server 7.14.

1. Encrypted request objects

OAuth 2.0 clients and OpenID relying parties can now submit authorisation requests to the server which parameters are kept confidential from the browser and end-user. The authorisation requests can be directly encrypted with JSON Web Encryption (JWE), or after signing them with JWS.

1.1 JWE algorithms

The following standard JWE algorithms are supported:

  • RSA encryption with RSA-OAEP-256, RSA-OAEP and RSA1_5. Note that use of RSA-PKCS1 v1.5 is no longer recommended and RSA-OAEP-256 should be used instead of RSA-OAEP.

  • ECDH encryption with ECDH-ES, ECDH-ES+A128KW, ECDH-ES+A192KW and ECDH-ES+A256KW.

  • AES 128, 192 and 256 bit encryption (dir) with a symmetric key derived from the client secret.

Two new configuration properties were introduced to set the enabled JWE algorithms and content encryption methods:

If the two configuration properties aren't set the Connect2id server will not accept encrypted request objects.

1.2 Server JWK set

If you intend to support public key encrypted request objects update the server JWK set to include the required RSA and EC encryption keys.

The public encryption keys will be published together with the public signing keys (for JWT validation), so clients that intend to submit RSA or ECDH encrypted authorisation requests can download them.

The server JWK set generator was updated to support creation and rotation of RSA and EC (P-256, P-384 and P-521 curve) encryption keys (v1.9).

Example EC key pair with P-256 curve marked for encryption use:

  "kty" : "EC",
  "crv" : "P-256",
  "use" : "enc",
  "kid" : "1yFA",
  "x"   : "_-aKZeuwWDv4v89dPGdKtpOuOepc_0qDZDhcv3omzX0",
  "y"   : "Gc5b7muOqbi4QvYJO24a4IqQoOY1pPM69DcpI605Vmw",
  "d"   : "lFj2hl_0MDs7D3yyTgU6LedcJ7NUZAs6noGzhZszsRA"

If only direct (dir) AES encryption based on client secrets is going to be used there is no need to generate and publish public RSA and EC encryption keys.

1.3 Client registration

Clients that intend to use encrypted request objects should declare that in their registration. Clients may also submit encrypted requests without explicitly registering for that, however, the registration gives them the opportunity to have the JWE algorithm parameters checked by the server.

Example client registration for RSA-OAEP-256 public key encryption with A128GCM content encryption:

POST /c2id/clients HTTP/1.1
Content-Type: application/json
Authorization: Bearer ztucZS1ZyFKgh0tUEruUtiSTXhnexmd6

  "redirect_uris"                 : [ "" ],
  "jwks_uri"                      : "",
  "request_object_encryption_alg" : "RSA-OAEP-256",
  "request_object_encryption_enc" : "A128GCM"

Example client registration for dir AES 128 bit encryption with a key derived from the client secret.

POST /c2id/clients HTTP/1.1
Content-Type: application/json
Authorization: Bearer ztucZS1ZyFKgh0tUEruUtiSTXhnexmd6

  "redirect_uris"                 : [ "" ],
  "jwks_uri"                      : "",
  "request_object_encryption_alg" : "dir",
  "request_object_encryption_enc" : "A128GCM"

1.4 Making encrypted requests

In order to submit an encrypted request object the OAuth 2.0 client needs to download the server JWK set and extract a public encryption keys from it that matches the desired JWE algorithm.

The request parameters are then encoded as claims into a JWT which is encrypted.

The following example using the open source OAuth 2.0 / OpenID Connect SDK that we maintain for the community shows how to do that, starting from the OpenID provider URL to discover all necessary endpoints and parameters.

import java.util.List;
import com.nimbusds.jose.*;
import com.nimbusds.jose.crypto.*;
import com.nimbusds.jose.jwk.*;
import com.nimbusds.jwt.*;
import com.nimbusds.oauth2.sdk.*;
import com.nimbusds.oauth2.sdk.client.*;
import com.nimbusds.oauth2.sdk.http.*;
import com.nimbusds.oauth2.sdk.token.*;
import com.nimbusds.openid.connect.sdk.*;
import com.nimbusds.openid.connect.sdk.op.*;

// Need OP issuer URL and access token for the registration as minimum
Issuer opIssuer = new Issuer("");
BearerAccessToken regEndpointToken = new BearerAccessToken("ztucZS1ZyFKgh0tUEruUtiSTXhnexmd6");

// Download OpenID provider metadata and JWK set
OIDCProviderMetadata opMetadata = OIDCProviderMetadata.resolve(opIssuer);
JWKSet opJWKSet = JWKSet.load(opMetadata.getJWKSetURI().toURL());

// Will use RSA-OAEP-256 and A128GCM encryption
assert opMetadata.getRequestObjectJWEAlgs().contains(JWEAlgorithm.RSA_OAEP_256);
assert opMetadata.getRequestObjectJWEEncs().contains(EncryptionMethod.A128GCM);

// Register client
ClientMetadata clientMetadata = new ClientMetadata();

HTTPResponse httpResponse = new ClientRegistrationRequest(

ClientRegistrationResponse regResponse = ClientRegistrationResponse.parse(httpResponse);

if (! regResponse.indicatesSuccess()) {

ClientInformation clientInfo = regResponse.toSuccessResponse().getClientInformation();

assert clientInfo.getMetadata().getRequestObjectJWEAlg().equals(JWEAlgorithm.RSA_OAEP_256);
assert clientInfo.getMetadata().getRequestObjectJWEEnc().equals(EncryptionMethod.A128GCM);

// Select public RSA encryption key from OP JWK set
List<JWK> rsaJWKs = new JWKSelector(new JWKMatcher.Builder()

if (rsaJWKs.isEmpty()) {
    System.err.println("No RSA encryption key(s) found in OP JWK set");

// Create encrypted OpenID auth request
RSAKey rsaJWK = (RSAKey)rsaJWKs.get(0); // use the first encryption key

EncryptedJWT jar = new EncryptedJWT(
    new JWEHeader.Builder(
    new AuthenticationRequest.Builder(
        new ResponseType("code"),
        new Scope("openid"),
        .state(new State())
jar.encrypt(new RSAEncrypter(rsaJWK));

AuthenticationRequest authRequest = new AuthenticationRequest.Builder(jar)

// Output the OpenID auth request

Learn more about request objects and their use in our excellent article.

2. Other features

The Connect2id server SDK was updated to v4.5 and now exposes an additional method in the ClaimsSourceRequestContext to find out how the sourced OpenID claims are going to be delivered - at the UserInfo endpoint or included in the ID token.

3. Resolved issues

The 7.14 release fixes a number of bugs related to request object processing, also a significant bug that prevented correct loading of JWK sets configured via the "jose.jwkSet" Java system property. Deployments that use this method to configure the server keys (instead of the regular WEB-INF/jwkSet.json) should update to 7.14.

There is more information in the release notes below.


To download a ZIP package of Connect2id server 7.14:

SHA-256: b4ce85678ee218e615aba0198d0d7649551887dcaa5a7f82e538f836caf3114a

As WAR package only:

SHA-256: c58b40906c6baa8e3369b2a7687fcbd02b20aedb4cabae64807984352db108e0


Contact Connect2id support.

Release notes

7.14 (2019-07-15)


  • Support for encrypted (JWE) request objects passed with the optional OAuth 2.0 request or request_uri authorisation request parameter. Supported are RSA (RSA-OAEP-256, RSA-OAEP, RSA1_5) and ECDH (ECDH-ES, ECDH-ES+A128KW, ECDH-ES+A192KW, ECDH-ES+A256KW) public key encryption as well as shared key encryption (dir) with an AES key derived from the client's secret.

    Clients can obtain the public encryption keys (with use=enc) from the Connect2id server JWK set endpoint.

    Clients must include their client_id as top-level authorisation request parameter when submitting request objects encrypted with an AES key derived from the client's secret, to enable the Connect2id server to lookup the secret.

    The JWK set generator for the Connect2id server was updated to support public encryption keys, see

    Processing of encrypted request objects conforms with the "OpenID Connect 1.0" and "The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR)" (draft-ietf-oauth-jwsreq-19) specifications.


  • /WEB-INF/jwkSet.json

    • Includes public RSA (2048 bit) and EC (P-256, P-384 and P-521) JSON Web Keys (JWK) with key use set to encryption (use=enc) for OAuth 2.0 clients to encrypt request objects to the Connect2id server. The presence of public encryption JWKs in the set is optional. Rotation is supported by prefixing new public encryption keys to the set (clients should use the first encryption key that matches the desired JWE algorithm).
  • /WEB-INF/

    • op.authz.requestJWEAlgs -- New optional configuration property listing the accepted JWE algorithms for encrypted OAuth 2.0 authorisation requests passed with the optional request_uri or request parameter. The default value is none.

      The following standard JWE algorithms are supported:

      • RSA-OAEP-256
      • RSA-OAEP (use no longer recommended)
      • RSA1_5 (use no longer recommended)
      • ECDH-ES
      • ECDH-ES+A128KW
      • ECDH-ES+A192KW
      • ECDH-ES+A256KW
      • dir
    • op.authz.requestJWEEncs -- New optional configuration property listing the accepted JWE content encryption methods for encrypted OAuth 2.0 authorisation requests passed with the optional request_uri or request parameter. The default value is none.

      The following standard JWE methods are supported:

      • A128CBC-HS256
      • A192CBC-HS384
      • A256CBC-HS512
      • A128GCM
      • A192GCM
      • A256GCM



    • Adds a new getClaimsTransport() method to the ClaimsSourceRequestContext to indicate how the OpenID claims are retrieved by the relying party. Returns "USERINFO" for the UserInfo endpoint, "ID_TOKEN" for including the claims in the issued ID token, and null if not applicable (the claims source SPI is invoked for another purpose, for example in a TokenEncoderContext).

Resolved issues

  • Fixes a bug which prevented loading of Connect2id server keys overridden or passed via the "jose.jwkSet" Java system property. Deployments that rely on loading the server JWK set via the "jose.jwkSet" Java system property must upgrade. The bug did not affect the multi-tenant Connect2id server edition (issue server/471).

  • OAuth 2.0 clients not explicitly registered for "request_object_signing_alg" must be able to use any supported JWS algorithm for signed request objects (JAR), provided the client has registered the necessary key material (public key or client secret) (issue server/469).

  • Remote JWK set (jwks_uri) sourcing errors when processing signed request objects should result in invalid_request_object error, not HTTP 500 (issue server/474).

  • When processing signed request objects a failed client JWK to Java key conversion should result in invalid_request_object error, not HTTP 500.

  • When serving UserInfo requests the "openid" scope value becomes required for the access tokens. Previously the UserInfo endpoint only checked that the access token permitted release of one or more OpenID claims. The OpenID scope values "profile", "email", "address" and "phone" will continue to be ignored in order to comply with data minimisation principles (issue server/473).

  • Updates the SQL DB connector to output a more detailed stack trace when parsing a corrupt JSON field in a SQL record.

Dependency changes

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

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

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

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

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

Connect2id server 7.13


This is a mini update to the Connect2id server for OpenID Connect and OAuth 2.0.

Check the release notes for more information.


To download a ZIP package of Connect2id server 7.13:

SHA-256: 8c31a2a41cd659b0c83eac89f0d4177eb889f694b118c5edb0936a13c8c7625b

As WAR package only:

SHA-256: 7c474253393ae6e66fdae77c3919af6338842892fa68db1c8ddeb5580d1d5510


Contact Connect2id support.

Release notes

7.13 (2019-06-25)


  • /WEB-INF/infinispan--redis-.xml

    • Upgrades the Redis store configuration XML schema to support two classes of store connectors - a simple connector supporting only load / store operations and an extended connector also supporting bulk operations.


  • /tenants/rest/v1/{tid}/metadata

    • New resource for storing arbitrary metadata (as JSON object) for a tenant. Supports GET and PUT. Available on the multitenant edition of the Connect2id server.


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

    • Provides a JWSVerifier in the context of the IdentifierAccessTokenCodec and SelfContainedAccessTokenClaimsCodec SPIs. Can be used to validate the JSON Web Signature (JWS) of custom hybrid access tokens (identifier-based access token encoded in a JWT with metadata) or custom secured fields in a token. Requires version 4.4 of the Connect2id server SDK.

Resolved issues

  • Works around an Infinispan issue which omitted objects in bulk retrieval operations in stateless deployments with a Redis cache and an underlying persisting database (SQL, LDAP). The issue affected listing of client registrations, authorisation records and tenants (in the multitenant edition) via the Connect2id server web APIs (issue server/467).

Dependency changes

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

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

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

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

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

  • Updates to com.nimbusds:common:2.34

  • Upgrades to com.nimbusds:infinispan-cachestore-common:2.4

  • Upgrades to com.nimbusds:infinispan-cachestore-redis:9.2.7

Connect2id server 7.12.1


This is a maintenance release of the Connect2id server. Fixes a bug in request object error reporting and a bug in the session store which affected the correct keeping of max idle time. Also updates the session store and the DynamoDB connector for better memory efficiency when purging large numbers of expired sessions.

Check the release notes for more information.


To download a ZIP package of Connect2id server 7.12.1:

SHA-256: 8a2743ae1e67249a689306ef2b660fb8f0adb902f31e502757a77243732bc346

As WAR package only:

SHA-256: f97a7a2cbc196e09d06f2351371b4af92191ac3a0ad9b12d4d3b0048a601c4ae


Contact Connect2id support.

Release notes

7.12.1 (2019-06-05)


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

    • Upgrades the DynamoDB store configuration schema to v1.6 which introduces a new optional "purge-limit" attribute. It limits the number of expired entries to purge during a run of the expired entry reaper task. The default value is -1 (no limit).

    • Adds new dymamodb.purgeLimit.sessionStore.sessionMap Java system property to set the purge limit for subject sessions persisted to DynamoDB. The default value is -1 (no limit).

Resolved issues

  • A JAR request for a client not registered for JAR should produce an invalid_request_object error with "The client isn't registered for request objects" message (issue server/461).

  • Fixes a session store bug which caused the last access timestamp for subject sessions to not update and the session to expire prematurely if max idle is set. The bug affected Connect2id server deployments in stateless cluster mode (DynamoDB and Redis) (issue session store/78).

  • Updates the session store task for purging orphaned subject keys (subject index entries) to conserve memory (issue session store/79).

  • Updates the expired entry purge task of the DynamoDB store to conserve memory (issue dynamodb/13).

Dependency changes

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

  • Updates to Infinispan 9.4.14.Final.

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

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