OpenID Connect articles

Key takeaways from the OAuth Security Workshop in Trento

Posted on 2018-03-19

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).

Connect2id server 6.18 allows token introspection responses to be JWTs

Posted on 2018-03-02

Updated token introspection

The Connect2id server can now return token introspection responses encapsulated in a signed JSON Web Token (JWT). The JWT can provide an additional layer of assurance where required by resource servers.

There are two ways to trigger a JWT to be returned for a token introspection response:

The JWT is signed with the same JWS algorithm and key used for the self-contained (JWT-encoded) access tokens.

Example introspection request:

POST /token/introspect HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Accept: application/jwt


Example introspection response encoded into a JWT:

HTTP/1.1 200 OK
Content-Type: application/jwt;charset=UTF-8


The extracted JSON object is a fully compliant token introspection response:

  "active"     : true,
  "token_type" : "Bearer",
  "iss"        : "",
  "sub"        : "n2cx7q2hqimjw",
  "scope"      : "read write",
  "iat"        : 1519995288,
  "exp"        : 1519995888,
  "client_id"  : "n2cx7q2hqimjw",
  "jti"        : "Yz5za_Yn7HI"

Note that the JWT output is a proprietary extension to RFC 7662.

JSON formatted logs and Logstash

The Connect2id server now packages a Log4j plugin to enable logs to be output in JSON format or piped to Logstash. Check the configuration howto.


To download a ZIP package of Connect2id server 6.18:

SHA-256: f985e8f199a82c656881bf54aa5096b02bb3d4aa719ecf55c44035edf5e8b0d0

As WAR package only:

SHA-256: da0868774f3c865b18aa30e21ae2d0362016c5d105c4600112864b95dfcbc486


Get in touch with Connect2id support.

Release notes

6.18 (2018-03-02)


  • /WEB-INF/oidcProviderProperties

    • op.token.introspection.alwaysRespondWithJWT — If true causes the token introspection responses to be always returned as a JWT signed with the same JWS algorithm and RSA key configured for self-contained (JWT) access tokens. The default value is false. This is a proprietary extension to RFC 7662, section 2.2.


  • /token/introspection

    • By passing an "Accept" HTTP request header set to "application/jwt" the Connect2id server will return the token introspection response as a JWT signed with the same JWS algorithm and RSA key configured for self-contained (JWT) access tokens. The default value is false. This is a proprietary extension to RFC 7662, section 2.2.

Resolved Issues

Dependency Changes

  • Adds com.github.dubasdey:log4j2-jsonevent-layout:0.0.4

Connect2id server 6.17 adds support for custom access token codecs, shaping of token introspection

Posted on 2018-02-26

The latest release of the Connect2id server for OpenID Connect identity provision opens new avenues for customisation. Three new SPIs were added, to enable plug in of alternative token codecs and for shaping of token introspection responses.

Self-contained access token claims codec

An SPI is provided for controlling what claims get included into JWT-encoded access tokens and how they get formatted. Resource servers which expect a particular structure or naming of the claims, such as for the non-standard JWT claims to represent scope or the client to which the token was issued, can benefit from this SPI.

The clear cut codec interface and the helpful base implementation make the job easy.

Identifier-based access token codec

When identifier-based access tokens are needed the Connect2id server generates secure random 128-bit numbers, with extra HMAC protection to detect and log fake tokens upon introspection.

Here also an SPI is provided for plugging in an alternative codec. For instance, to encapsulate the identifier in a signed JWT, along with the issuer URL, expiration time and client certificate confirmation, to provide resource servers in multi-tenant deployments with a hint where to introspect the token, and also allow part of the token validation to be done locally by the resource server, before the introspection call.

  "iss" : "",
  "jti" : "Hoofao7Ve1ohg4chahBee9Xee1ahvaed",
  "exp" : 1519660677,
  "cnf" : { "x5t#S256" : "Shoohie2Pee1ubi9aehai3leg0woidet" }

Token introspection

Shaping of token introspection responses is supported to control what token details a resource can see. For example, to limit the introspected scope only to those scope values which the resource server supports. This is can be important for data minimisation in authorisation server deployments with different service providers, or where access tokens can have multiple audiences.

Example introspection response for a token for two resource servers:

  "active"     : true,
  "iss"        : "",
  "scope"      : "",
  "token_type" : "Bearer",
  "sub"        : "alice"

Shaping the response for the service:

  "active"     : true,
  "iss"        : "",
  "scope"      : "",
  "token_type" : "Bearer",
  "sub"        : "alice"

Shaping the response for the service:

  "active"     : true,
  "iss"        : "",
  "scope"      : "",
  "token_type" : "Bearer",
  "sub"        : "alice"


To download a ZIP package of Connect2id server 6.17:

SHA-256: af37f5b29191178bbda93290b806f95ee495a4cc8a9dad4ce097d87d0918664d

As WAR package only:

SHA-256: fd9d057b99580d158c7ef247acda7452f0da319a25871d0ca29ef131305748d1


Get in touch with Connect2id support.

Release notes

6.17 (2018-02-26)


  • /WEB-INF/

    • accessToken.allowDirectInspection — The default setting becomes false (always require the master API token for inspecting access tokens at the /authz-store/rest/v2/inspection endpoint). The change is made to encourage resource servers to use the standard /token/introspect endpoint which requires the introspection request to be authenticated or authorised with an access token.

    • accessToken.selfContainedClaims — The setting for specifying the JWT claims to include in self-contained access tokens is no longer supported. If such customisation is required this can now be implemented via the SelfContainedAccessTokenClaimsCodec SPI (see below).


  • No changes


  • IdentifierAccessTokenCodec — Adds new optional SPI for customis generation and decoding of identifier-based access tokens. The SPI invocation context provides access to a secure random generator, an HMAC computer, a JWT signer and the OpenID claims source of the Connect2id server.

  • SelfContainedAccessTokenClaimsCodec — Adds new optional SPI for custom encoding and decoding of JWT claims in self-contained access tokens. The SPI invocation context provides access to a secure random generator, an HMAC computer, a JWT signer and the OpenID claims source of the Connect2id server.

  • TokenIntrospectionResponseComposer — Adds new optional SPI for custom composition of token introspection (RFC 7662) responses. The SPI invocation context provides access to the OpenID claims source of the Connect2id server and the registered information of the requesting client (for introspection requests with client authentication).

  • IDTokenIssueEventListener — Updates the SPI method to include EventContext (breaking change from v6.16).

  • AccessTokenIssueEventListener — Updates the SPI method to include EventContext (breaking change from v6.16).

Resolved Issues

  • Always encrypts issued self-contained (JWT) access tokens when the OpenID relying party is registered for pairwise subject identifiers. This is done to prevent leakage of the underlying subject identifier. Previously the consent logic driving the authorisation session had to explicitly take care of that by setting access_token.encrypt in the consent object to true (issue server/349).

  • Updates logging of client IP in HTTP requests to take into account Forwarded (RFC 7239) and X-Forwarded-For headers set by reverse proxies (issue common/57).

  • Fixes NoSuchMethodError on Dropwizard HealthCheckRegistry shutdown (issue server/341).

  • Logs cause of self-contained (JWT) access token failing inspection.

Dependency Changes

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

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

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

  • Upgrades to com.nimbusds:common:2.22

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

  • Upgrades to com.thetransactioncompany:java-property-utils:1.13

  • Upgrades to com.nimbusds:infinispan-cachestore-sql:2.7

  • Upgrades to BouncyCastle 1.59

  • Upgrades to Dropwizard Metrics 3.2.6.

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

  • Upgrades to Apache Commons Lang 3.7

  • Upgrades to Log4j 2.10.0

Open Banking workshops in London

Posted on 2018-01-15

Open Banking is moving ahead. The OIX and OpenID Foundation are organising two workshops for implementers, on 30 January 2018 in London.


  • OIX: Consumer trust study
  • OIX: Opening a bank account across borders with an EU national eID
  • OpenID: Financial read / write API v2
  • OpenID: Discussion on the PSD2 regulatory technical standards for user authentication: redirect vs embedded vs decoupled

Registration for the two workshops is free. Details:

To speak to us, look for Vladimir Dzhuvinov, our CEO and identity architect, who will be attending the event.