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

Posted on 2018-04-02

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" : "https://demo.c2id.com",
  "sub" : "izad7cqy34bg4",
  "cid" : "izad7cqy34bg4",
  "scp" : [ "client-reg" ],
  "aud" : [ "https://demo.c2id.com/clients/" ],
  "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" : "https://demo.c2id.com",
  "sub" : "izad7cqy34bg4",
  "cid" : "izad7cqy34bg4",
  "scp" : [ "client-reg" ],
  "aud" : [ "https://demo.c2id.com/clients/" ],
  "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
Host: demo.c2id.com
Authorization: Bearer ztucZS1ZyFKgh0tUEruUtiSTXhnexmd6

The response will then be a minimal 204:

HTTP/1.1 204 No Content

Download

To download a ZIP package of Connect2id server 6.19:

https://connect2id.com/assets/products/server/download/6.19/Connect2id-server.zip

SHA-256: 8d5e343373297ab9813a46039a94acf60771c88f86cf16e46772bb5d0e46c3b4

As WAR package only:

https://connect2id.com/assets/products/server/download/6.19/c2id.war

SHA-256: 3d22ee822da2a75832ab214ab7f6540020565c8c7a051246732a68e0eb9b0773

Questions?

Get in touch with Connect2id support.


Release notes

6.19 (2018-04-02)

Configuration

  • /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.

Web API

  • /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

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
Host: c2id.com
Content-Type: application/x-www-form-urlencoded
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Accept: application/jwt

token=ohDaa4co3ohthohm.uochoh8ahhie6Yoo

Example introspection response encoded into a JWT:

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

eyJraWQiOiJDWHVwIiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiJuMmN4N3EyaHFpbWp3Iiwic2NvcGUi
OiJyZWFkIHdyaXRlIiwiaXNzIjoiaHR0cDpcL1wvMTI3LjAuMC4xOjgwODBcL2MyaWQiLCJhY3RpdmU
iOnRydWUsInRva2VuX3R5cGUiOiJCZWFyZXIiLCJleHAiOjE1MTk5OTU4ODgsImlhdCI6MTUxOTk5NT
I4OCwiY2xpZW50X2lkIjoibjJjeDdxMmhxaW1qdyIsImp0aSI6Ill6NXphX1luN0hJIn0.R2eUTnt0r
KVMs8D9nS91OWmyF-fskdcCxp-d8dVZxOZV-4wtviXOFMB5IMcWyMoJF73r7z112dolT_sJxQ22Nebm
lbtrulfJZZkSGpegPZU6Ze93hM0ll0KDhuP-Ya9oNwtPg-HZ_NWGz2ObsjPLgp7YJZN0gPc4MpAvhrR
kxDMNBFSj6E7CsgEz2O6q3TJRun5XlRCiJAMAK9Axo4HpWqFTYubGV_rRfJAgfiV3d5BYhAvUyigTBB
ojDDNGErgOgZYk7KBLztR9-YqvZbcDgjFNjQpr1kIxR5Cq877gSyqfanBp8RvPTqyy9VxAGSiuQnYHP
1h6yKrunAvdODVZvA

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

{
  "active"     : true,
  "token_type" : "Bearer",
  "iss"        : "https://demo.c2id.com",
  "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.

Download

To download a ZIP package of Connect2id server 6.18:

https://connect2id.com/assets/products/server/download/6.18/Connect2id-server.zip

SHA-256: f985e8f199a82c656881bf54aa5096b02bb3d4aa719ecf55c44035edf5e8b0d0

As WAR package only:

https://connect2id.com/assets/products/server/download/6.18/c2id.war

SHA-256: da0868774f3c865b18aa30e21ae2d0362016c5d105c4600112864b95dfcbc486

Questions?

Get in touch with Connect2id support.


Release notes

6.18 (2018-03-02)

Configuration

  • /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.

Web API

  • /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