Hardware Security Module (PKCS#11) support in Connect2id server 6.3

Posted on 2017-01-30

HSM device

The Connect2id server can now utilise Hardware Security Modules (HSM) for signing issued identity and access tokens. By performing the cryptographic operations on a dedicated external device, and with no logical access to the private keys, the HSM provides an excellent security guarantee against key theft. This makes HSMs indispensable in applications which require a high degree of security, such as national eID schemes and in payments.

The HSM is accessed from the Connect2id server via a PKCS#11 interface, which has been the established standard for such devices since 1995.

You can find out more about HSM configuration in the Connect2id server manual. RSA as well as EC keys are supported. Roll-over of the signing keys is done automatically, based on the validity window of their X.509 certificates.

Check the release notes below to find out what else has been updated in Connect2id server v6.3.


To download a ZIP package of Connect2id server 6.3:


(SHA-1: 14fca0357036a322a85d9442c55e96ca269f37f3)

As WAR package only:


(SHA-1: 4b6a57f384df93b3d801c76643e211167bcf4b0c)


Get in touch Connect2id support, we’ll be delighted to help out.

Release notes

6.3 (2017-01-30)


  • Adds comprehensive support for signing issued ID and self-contained access tokens with RSA and EC keys stored in a PKCS#11 compliant Hardware Security Module (HSM). Supports automatic key rollover based on the not-before and not-after dates specified in the X.509 certificate of each PKCS#11 based RSA and EC key intended for signing.


  • /WEB-INF/jose.properties

    • Introduces new optional configuration file for loading RSA and EC signing JSON Web Keys (JWK) from a PKCS#11 compliant HSM.
  • /WEB-INF/hsm.cfg

    • Adds sample configuration file for the Java SUN PKCS#11 security provider (to enable loading of a PKCS#11 compliant HSM).
  • /WEB-INF/web.xml
    • Adds com.nimbusds.jose.jwk.loader.JWKSetLoader listener.


  • No changes


  • Logs a detailed message at level "INFO" for a token request with JWT client authentication (client_secret_jwt, private_key_jwt) where the JWT has expired or the claims validation failed (issue sdk/204).

Bug fixes

  • Outputs a proper OAuth 2.0 invalid_client error if a token request includes multiple client authentication methods (issue sdk/203).

  • Fixes a bug which caused the BouncyCastle JCA provider to be loaded if "none"
    is detected among the supported ID token JWS algorithms (non-critical).


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

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

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

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

  • Adds new com.nimbusds:nimbus-jwkset-loader:1.2.2 dependency.

  • Upgrades to org.bouncycastle:bcprov-jdk15on:1.56

  • Upgrades to org.bouncycastle:bcpkix-jdk15on:1.56

  • Upgrades to Infinispan 8.2.6.Final

  • Upgrades to JAX-RS Jersey 2.25.1

  • Upgrades to Log4j 2.8

Connect2id server 6.2 makes it easier to implement stateless login / consent front-ends

Posted on 2017-01-12

This new release of the OpenID Connect / OAuth 2.0 server makes it easier to implement nible stateless UIs on top of it. It also exposes Redis client connection pool metrics (initially appeared in v5.0.5) for those of you who choose to deploy the Connect2id server in a two-tiered manner, with Redis / AWS ElastiCache providing the main in-memory store, and Infinispan the secondary (in invalidation mode).

Stateless front-ends

Stateless front-ends are good, because they are easy to maintain, deploy and scale.

One of the defining features of the Connect2id server is the avoidance of any hard-wired UIs; the server comes instead with a set of elegant web APIs so that all UI, such as login and consent interaction, is decoupled, and can be developed, tested and deployed independently. We have a nice guide explaining the advantages and mechanics of that.

Version 6.2 adds a new optional data parameter to the authorisation session, which can be used to store arbitrary state while the end-user credentials are being checked and consent is obtained. This may also include the duration to redirect to an external authentication service or another identity provider (IdP).

For example, the login page may offer the option to sign in with another IdP, such as Google or Twitter. Before the user gets redirected to the IdP of their choice, the state can be stored in the data parameter of the current authorisation session. Upon returning from the IdP, the state is resumed, and the login interaction can continue.

The data can be set at the start of the authorisation session, or at any time after that with a PUT call. To read the stored data do a GET for the authorisation session or a direct GET for the data sub-resource.

Check out the updated authorisation session API reference for details.

Redis connection pool metrics

If you have a Connect2id server cluster deployed with Redis / AWS ElastiCache as primary in-memory store and want to fine tune your Redis connection pools, these new metrics will provide you with the necessary data.

The new Redis connection pool gauges are made available at the existing /monitor/v1 endpoint, which already collects more than 100 metrics for all sorts of things.

Example Redis client connection pool metrics:

    "sessionStore.sessionMap.redisStore.numActiveConnections": {
      "value": 1
    "sessionStore.sessionMap.redisStore.numIdleConnections": {
      "value": 6
    "sessionStore.sessionMap.redisStore.numWaitingForConnection": {
      "value": 0
    "sessionStore.sessionMap.redisStore.maxWaitingTimeForConnectionMs": {
          "value": 15
    "sessionStore.sessionMap.redisStore.meanWaitingTimeForConnectionMs": {
      "value": 0


To download a ZIP package of Connect2id server 6.2:


(SHA-1: a84329a865d8fa5ed49f2c937bb2e9300706b51a)

As WAR package only:


(SHA-1: 6ba80693c0fa0e46c0849d41358d9af892d58274)


Get in touch Connect2id support, we’ll be delighted to help out.

Release notes

6.2 (2017-01-12)


  • No changes


  • /authz-sessions/rest/v3/

    • Enables storage of additional data in the authorisation session, to enable use cases such as a stateless login front-end that needs to perform a redirection to an external service or IdP as part of the authentication or consent process.
      • Adds new optional "data" parameter of type JSON object to the authorisation session.
      • The optional "data" can be set with the initial POST request for a new authorisation session, or with a dedicated PUT request to the authorisation session data resource.
      • The optional "data" can be retrieved with a GET for the authorisation session, or directly from the authorisation session data resource.
  • /monitor/v1/metrics
    • Adds Redis store connection pool metrics (of type gauge):
      • "[infinispan-cache-name].redisStore.numActiveConnections" — the number of active Redis client connections in the pool.
      • "[infinispan-cache-name].redisStore.numIdleConnections" — the number of idle Redis client connections in the pool.
      • "[infinispan-cache-name].redisStore.numWaitingForConnection" — the number of threads waiting for a Redis client connection.
      • "[infinispan-cache-name].redisStore.meanWaitingTimeForConnectionMs" — the mean time waiting to borrow a Redis client connection from the pool, in milliseconds.
      • "[infinispan-cache-name].redisStore.maxWaitingTimeForConnectionMs" — the maximum time waiting to borrow a Redis client connection from the pool, in milliseconds.

Bug fixes

  • None


  • Upgrades to Nimbus JOSE+JWT 4.34.

  • Upgrades to Redis Store 8.2.1 (private Connect2id release)

Certified OpenID Connect provider server

Posted on 2017-01-09

Last week the Connect2id server received certification for all standard OpenID Connect provider profiles, which also extends to the optional advanced security features that we implemented in 2016:

  • JWT client authentication — Offers a number of security advantages over the common HTTP basic authentication, such as preventing credential leakage if the HTTP request is sent in the plain by accident.
  • Client keys — Clients and relying parties can bring their own assymetric keys (RSA and EC), in order to authenticate with a JWT, or to receive encrypted ID tokens and UserInfo.
  • Encryption — ID token and UserInfo encryption, using a public RSA or EC key registered by the client, or an AES key derived from the client’s secret.
  • Signed authorisation requests — authenticate and integrity-protect the initial OpenID authentication and OAuth 2.0 authorisation requests. Work nicely with public / native clients, regardless of the nature of their registration, to ensure the important parameters get "locked down", and cannot be modified by the end-user or app.
  • Pairwise identifiers — Method (to be used in conjunction with others) that makes it harder for relying parties to correlate the identity of logged in users.

Other organisations that received OpenID provider certification during the same period are Yahoo! Japan and Verizon.

Many thanks to Roland Hedberg, who manages the certification suite at OpenID, for assisting us with the tests, even though it was holiday time, and he probably had better things to do.

We would also like to thank Mike Jones, secretary of the OpenID foundation, for his recognition of Connect2id’s service to the OpenID Foundation and the OpenID community since 2012.