Connect2id server 6.19.1 maintenance release


This maintenance release of the Connect2id server fixes a bug in the old version 2 of the authorisation session API for identity providers who use the form_post response mode, or a custom response mode. See the change log below for details.

Version 2 of the authZ session API was introduced in Connect2id server 3.0 (2015-03-26) and was superseded by the current version 3, in Connect2id server 5.0 (2016-05-17).


To download a ZIP package of Connect2id server 6.19.1:

SHA-256: 09d885d7856794cf86ea711841223ab5d5d39217013aadc17ac99aa66e13e439

As WAR package only:

SHA-256: a36c2571733061f8574f46de9eebb8b406f905b3bf07a1ced70169474fa347b8


Get in touch with Connect2id support.

Release notes

6.19.1 (2018-04-20)

Resolved Issues

  • Fixes a bug in the old v2 of the authorisation session API (/authz-sessions/rest/v2) which prevented ID token output in the final OpenID authentication response for response types "id_token" and "token id_token" in combination with a "form_post" or a custom response mode (issue server/361).

Connect2id server 6.19 updates the client registration and the session store APIs


Today's release of the OpenID Connect server updates the web API for registering clients and relying parties. It also adds a flag to disable web API output when deleting all end-user sessions.

Initial access tokens for the registration endpoint can now be client X.509 certificate bound

As you know client applications need to be registered with the server before they can request tokens from it. The registration endpoint is normally protected and requires a token. This can be the configured master access token or a regular token issued by the Connect2id server, via some OAuth flow, that includes the client-reg scope and endpoint URL as the audience.

Here are the JWT claims for one such initial access token:

  "iss" : "",
  "sub" : "izad7cqy34bg4",
  "cid" : "izad7cqy34bg4",
  "scp" : [ "client-reg" ],
  "aud" : [ "" ],
  "iat" : 1448324500,
  "exp" : 1448367412

In 2017 we introduced support for client certificate bound access tokens, a simple yet effective measure to prevent replay by an unauthorised party if the client somehow leaks the token. This security feature is being developed at the OAuth working group, to fix the bearer weakness of regular OAuth tokens.

Starting with today's 6.19 release, the client registration endpoint of the Connect2id server will detect and enforce initial access tokens that are bound to a client's certificate. The binding is set by the SHA-256 thumbprint (cnf.x5t#S256) of the client's X.509 certificate.

Here are the JWT claims for a token that is bound that way:

  "iss" : "",
  "sub" : "izad7cqy34bg4",
  "cid" : "izad7cqy34bg4",
  "scp" : [ "client-reg" ],
  "aud" : [ "" ],
  "iat" : 1448324500,
  "exp" : 1448367412,
  "cnf" : { "x5t#S256" : "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2" }

When the registration request is made, if no client certificate is submitted, or there is a mismatch between the encoded thumbprint and that of the client certificate presented during the TLS handshake, the following bearer token error will get returned:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer error="invalid_token" error_description="Missing / invalid client X.509 certificate for x5t#S256 bound access token"

Configuration to disable the audience restriction of initial access tokens

As we mentioned above, the initial access tokens are expected to have an audience that includes the registration endpoint URL. If you need to disable this check we created a new op.reg.requireInitialAccessTokenAudience configuration setting for that.

op.reg.requireInitialAccessTokenAudience = false

The default setting is true (audience always required).

Disabling output when deleting all end-user sessions

The Connect2id server provides a special API call that delete all end-user sessions with the OpenID provider / authorisation server at once, thus causing all users to get logged out.

This call normally returns a JSON map of all user sessions, which may become a problem and cause timeouts if millions of sessions are present in the store.

To disable output we introduced a quiet query parameter:

DELETE /session-store/rest/v2/sessions?all=true&quiet=true HTTP/1.1
Authorization: Bearer ztucZS1ZyFKgh0tUEruUtiSTXhnexmd6

The response will then be a minimal 204:

HTTP/1.1 204 No Content


To download a ZIP package of Connect2id server 6.19:

SHA-256: 8d5e343373297ab9813a46039a94acf60771c88f86cf16e46772bb5d0e46c3b4

As WAR package only:

SHA-256: 3d22ee822da2a75832ab214ab7f6540020565c8c7a051246732a68e0eb9b0773


Get in touch with Connect2id support.

Release notes

6.19 (2018-04-02)


  • /WEB-INF/oidcProviderProperties

    • op.reg.requireInitialAccessTokenAudience -- If true the initial registration access token must include an audience value that is the OpenID Provider / Authorisation Server issuer URI or the client registration endpoint URI, else the access token won't be accepted. Defaults to true.


  • /clients

    • The client registration endpoint adds support for initial access tokens that are client X.509 certificate bound (see draft-ietf-oauth-mtls-07).
  • /session-store/rest/v2/sessions

    • Adds support for an optional "quiet" query parameter when deleting all subject (end-user) sessions from the store. When set to true an HTTP 204 No Content response will be returned and the deleted sessions will not be included in the response body.

Dependency Changes

  • Upgrades to session store 6.0.

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

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

  • Upgrades to com.nimbusds:nimbus-jwkset-loader:1.5

  • Upgrades to com.nimbusds:tenant-manager:1.4

  • Upgrades to com.nimbusds:tenant-manager:1.4

  • Upgrades to com.unboundid:unboundid-ldapsdk:4.0.5

Key takeaways from the OAuth Security Workshop in Trento


The OAuth security framework is not static. It keeps evolving, driven by new applications, often in hot fields such as open banking, payments and IoT. The 2018 edition of the OAuth Security Workshop was a three day event where we discussed original use cases brought forward by brave developers and explored new extensions to the framework.

Here are my personal key takeaways.

Logout explained

Much has been said about single sign-on (SSO), but not about logout, especially in the context of OpenID Connect federation. Thanks to the superb work of Brock Allen and Mike Jones, we now have a draft for a comprehensive guide on what logout can mean (semantics) and how to implement it (mechanisms) in various scenarios.

We agreed that the design of logout should always begin by answering these two questions:

  • What are the users' natural expectations from logout in a given scenario?
  • What security requirements does the application have?

With a clear picture of that we can then go ahead and select appropriate logout triggers and mechanisms.

Possible logout triggers:

  • End-user action, e.g. clicking on sign-out button
  • Application session time-out
  • IdP session time-out
  • Detection of anomalous behaviour or account compromise
  • Account termination

Useful criteria for selecting a logout mechanism:

  • Reliable or best effort? Front-channel logout (via browser redirect or iframe messaging) is relatively easy to implement, but also brittle. If reliability is sought a back-channel method must be considered.
  • Type of logout messaging: request, confirmation, or both?
  • Direction of logout messaging: RP -> IdP and / or IdP -> RP
  • Whether the user is logged out from the application or also from the IdP?
  • Which state is cleared / revoked and which kept: cookies, access tokens, refresh tokens, HTML5 local state, etc.

OpenID Connect already provides four mechanisms related to logout:

AES-SIV mode for JSON Web Encryption (JWE)

JSON Web Tokens (JWT) are widely used in OAuth for self-contained access tokens. They are usually signed, but can also be additionally encrypted, when the token carries claims that must be kept confidential from clients.

There are two standard methods for JWT encryption at present -- AES/CBC with HMAC/SHA-256 and AES/GCM.

Both provide strong authenticated encryption. Their security properties rely on the IV being being sufficiently random (AES/CBC), or the nonce non-repeating (AES/GCM). If these conditions aren't met, the security properties of the encryption crumble, sometimes dramatically. The availability of a secure random generator can indeed be a problem, in constrained IoT devices or in VMs where good entropy for seeding of the generator is difficult to come by.

To mitigate against such risks Neil Madden suggested a new JWE content encryption method based on AES in SIV mode (RFC). For use in JOSE he put together draft-madden-jose-siv-mode-02. The draft also specifies a key wrapping mode based on AES-SIV.

The proposed enc identifiers for JWE:

enc Description
A128SIV AES SIV using CMAC and 256 bit key
A128SIV-HS256 AES SIV using HMAC-SHA-256-128 and 256 bit key
A192SIV-HS384 AES SIV using HMAC-SHA-384-192 and 384 bit key
A256SIV-HS512 AES SIV using HMAC-SHA-512-256 and 512 bit key

Here is link to Neil's slides on misuse-resistant JOSE encryption with AES-SIV and a detailed paper with references.

New OAuth flows for payment, open banking and IoT

New flows keep popping up and this is a testament to OAuth finding use in new areas.

  • Do you have a scenario where the client is on a different device than the one where the user authenticates and gives consent? This can occur in situations involving POS terminals, smart TVs, or delegating access to a service person. Take a look at Dave Tonge's presentation of decoupled flows in OAuth 2.0.
  • Torsten Lodderstedt has done a great job in winning over the Berlin Group to consider OAuth in the PSD2 API it is developing. He presented a modified OAuth code flow with Strong Customer Authentication (SCA).
  • Hannes Tschofenig gave a talk on OAuth for IoT, and we discussed a "client token" flow where the ACE / OAuth client uses the resource server to tunnel the token request to the authorisation server.


I had fantastic time in Trento. When we parted on Friday I thanked our wonderful hosts for their hospitality and told them I hoped there would be another OAuth event there!

The next OAuth Security Workshop will take place in Stuttgart, in the week before the IETF 104 meeting in Prague (23 - 29 March 2019).