OAuth 2.0 articles

Connect2id server 6.7.1

Posted on 2017-05-21

Execute custom logic during prompt=none processing

The latest 6.7 release of the Connect2id server makes it easier to execute custom logic during processing of OpenID prompt=none authentication requests. Clients use the optional prompt=none parameter to "silently" check if the present user is still logged in with the identity provider. If not (signalled by a login_required error), the user is sent back to the OpenID server to re-authenticate.

The new op.authz.alwaysPromptMode configuration setting allows integrators to have a custom script step into the the processing of prompt=none requests, including login_required and consent_required error conditions.

To that end the authorisation session JSON object now also keeps a record of the requested prompt parameter.

Control authorisation response errors

When authorisation is denied the login page / authorisation logic can now specify an OpenID / OAuth 2.0 error code other than the default access_denied to be returned to be client. Unless you intend to implement some quite custom authorisation rule, you need not be concerned with this option; simply leave error processing to the Connect2id server.

Session store fixes for Redis backends

The day when v6.7 was about to be released we had to tackle an issue which prevented new session creation in Connect2id server deployments with Redis as the primary in-memory store (and Infinispan in invalidation mode). Several fixes were made to the session store to address this, hence the combined announcement of 6.7 and 6.7.1 here. If you’re using Redis as backend updating to 6.7.1 is highly recommended.


To download a ZIP package of Connect2id server 6.7.1:


(SHA-256: 7a0bb9f78b3d313ae25be54aa6d8ac686c5eb473bd4e5f7324f574b43cbb45ab)

As WAR package only:


(SHA-256: 7f79eb5e5098ecb1c7b391938399d5605c875330f51e8d215af457117c31e763)


Get in touch with Connect2id support.

Release notes

6.7.1 (2017-05-21)


  • No changes


  • No changes


  • Fixes a bug affecting subject session mapping removal and also potentially affecting new subject session addition when Infinispan is configured in invalidation mode (typically with Redis as primary in-memory store / cache) (issue session-store/55).

  • Fixes concurrency bug which caused the periodic clean up of orphaned subject session mappings to cease if the session store is configured with a persisting backend, such as Redis or an SQL database (issue session-store/53).

  • Fixes sessionStore.sessionExpirations metering for subject sessions which are expired externally by a persisting backend (issue session-store/57).

  • Forces clean up of orphaned subject session mappings if the mapping routine cannot free up a session slot after 10 iterations. Also makes the periodic task for cleaning up orphaned subject session mappings resilient to runtime exceptions (issue session-store/59).


  • Upgrades to com.nimbusds:oidc-session-store:5.2.2

6.7 (2017-05-18)


  • /WEB-INF/oidcProvider.properties

    • Adds new op.authz.alwaysPromptForAuth configuration setting to control processing of OpenID prompt=none authentication requests when op.authz.alwaysPromptForAuth or op.authz.alwaysPromptForConsent is enabled:
      • LIMITED — No authentication or consent prompt will be returned on a OpenID prompt=none authentication request. The Connect2id server will proceed straight to returning the final response (success or login_required / consent_required error).
      • PROMPT_NONE — An authentication or consent prompt will be returned on a OpenID prompt=none authentication request provided an existing session or consent is found and the request can be fulfilled with no end-user interaction. This is the default mode for legacy reasons.
      • PROMPT_NONE_WITH_INTERACTION_ERRORS — An authentication or consent prompt will be returned on a OpenID prompt=none authentication request even if the request cannot be fulfilled due to required end-user interaction; in that case the login page must handle the login_required and consent_required errors by itself.


  • /authz-sessions/rest/v3/

    • Adds a new auth_req.prompt field to the authorisation session JSON object, representing the value of the optional OpenID prompt authentication request parameter (if set).

    • Adds a new optional "error" and "error_description" query parameters to DELETE requests to allow the login page to signal a different OpenID Connect / OAuth 2.0 error other than "access_denied" when cancelling an authorisation session. Can for example be used to signal an internal login page error with "server_error" or "temporarily_unavailable". All standard OpenID Connect / OAuth 2.0 error codes returned with an authorisation error response are supported: access_denied (default), invalid_request, unauthorized_client, unsupported_response_type, invalid_scope, server_error, temporarily_unavailable, login_required, consent_required, interaction_required, account_selection_required, request_uri_not_supported, request_not_supported, invalid_request_uri and invalid_request_object.


  • None


  • No changes

Connect2id server 6.6.2 strengthens defences against timing attacks

Posted on 2017-04-26

The OpenID Connect server has now stronger defences in place against timing attacks on OAuth 2.0 client secrets (used in HTTP basic authentication) as well as the master API tokens used to integrate the IdP / AS server with other internal services.

Submitted client secrets are not just compared in constant time manner (to the extent that’s possible with the Java runtime), but this comparison is now done using a (salted) SHA-256 hash of the secret. With such a three-layered defence (salt, hash, constant time string comparison) security shall be greatly enhanced.

The 6.6.2 release also updates a few of the underlying dependencies and fixes a bug related to Infinispan (with Redis and SQL as backends).


To download a ZIP package of Connect2id server 6.6.2:


(SHA-256: feb26baa5137f658ce7ca9cab20ae94a5ea2e0251af1c09cc23c27821a50225f)

As WAR package only:


(SHA-256: 4cec583dae1b2f4f2a2a49d43acc2e0067ba88d409eb48ebdd9d0e9d346a3c3f)


Contact Connect2id support.

Release notes

6.6.2 (2017-04-26)


  • Switches to constant time comparison in the master web API token validation routines to guard against side-channel / timing attacks. The token values are salted and hashed with SHA-256 before comparison for additional protection.

  • Switches to constant time comparison in the client_secret validation routine to guard against side-channel / timing attacks. The client_secret values are hashed with SHA-256 before comparison for additional protection.


  • /WEB-INF/jwkSet.json

    • Checks the supplied elliptic curve (EC) keys on Connect2id server startup to ensure the public ‘x’ and ‘y’ parameters match the curve (P-256, P-384 or P-521).


  • No changes

Bug fixes

  • Fixes intermittent duplication of client objects when listing all clients via the client registration web API (HTTP GET) for Infinispan setups in invalidation mode with Redis as primary cache and an SQL database as persistence store (issue #273).


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

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

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

  • Upgrades to com.nimbusds:common:2.5

Connect2id server 6.6.1 maintenance release

Posted on 2017-04-12

This is a small maintenance release of the Connect2id server.


  1. Fixes client_secret provisioning client_secret_jwt authentication with HS384 and HS512 at the token endpoint to ensure the client secret is of sufficient length for the HMAC algorithm.

  2. Upgrades several dependencies under the hood - the OAuth 2.0 / OpenID Connect SDK, Nimbus JOSE+JWT, the JDBC connector for MySQL databases and Log4j.


To download a ZIP package of Connect2id server 6.6.1:


(SHA-256: a8360793842a68aa3758682bf16b69a7bf1aac9f6ffb309b609a7518e922d549)

As WAR package only:


(SHA-256: 7dd33494e40a889cbcd4427117af1d08d4b28539a4402b916c62dff1b1fca739)


Get in touch Connect2id support to receive assistance.

Release notes

6.6.1 (2017-04-12)


  • No changes


  • No changes

Bug fixes

  • For client_secret provisioning for client_secret_jwt authentication with HS384 and HS512 at the token endpoint to ensure the client secret is of sufficient length for the HMAC algorithm (issue #272).


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

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

  • Upgrades to mysql:mysql-connector-java:5.1.41

  • Upgrades to Log4j 2.8.2

New OAuth spec for TLS client authentication with X.509 certificate

Posted on 2017-04-06

Brian Campbell and other members of the OAuth WG published a new spec for letting clients authenticate with TLS and a X.509 certificate to the token endpoint of an OAuth / OpenID Connect server. The issued access token includes a hash (thumbprint) that binds it to the client’s certificate, preventing misuse of the token if it’s stolen.

Open banking applications in Europe, where X.509 certificate based authentication is required by law, will find this spec indispensable.

How does this new method for OAuth client authentication work?

  1. The client registers for TLS authentication with the OAuth 2.0 server, and also provides the subject and issuer DNs of the X.509 certificate(s) that it is going to use.

    POST /register HTTP/1.1
    Content-Type: application/json
    Accept: application/json
    Host: demo.c2id.com
     "redirect_uris"              : [ "https://client.example.org/callback" ],
     "client_name"                : "My Banking App",
     "token_endpoint_auth_method" : "tls_client_auth",
     "tls_client_auth_subject_dn" : "cn=mybankingapp.com",  
     "tls_client_auth_issuer_dn"  : "cn=trustedca.com"  
  2. At the token endpoint the client sends the usual request, but instead of using basic or JWT authentication, it authenticates via TLS using its X.509 certificate.

  3. The OAuth / OpenID Connect server issues an access token with a special cnf.x5t#s256 field specifying the hash (thumbprint) of the client’s certificate.

     "iss" : "https://demo.c2id.com",
     "aud" : "https://open.bank.com",
     "sub" : "[email protected]",
     "scp" : [ "openid", "email", "check-balance" ],
     "exp" : "1493726400",
     "nbf" : "1493722800",
     "cnf" : { "x5t#s256" : "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2" }
  4. At the protected resource server (web API) the client submits its access token while also authenticating via TLS using its certificate.

  5. The resource server validates the certificate, the token and finally, whether their binding is correct. If these checks pass, the request can proceed.

We hope this spec will be adopted as an official working item by the OAuth, so that it can eventually become an RFC.

For more information:

You can post questions or comments on this spec below, or write to the OAuth WG.