Connect2id server 6.6.1 maintenance release

Posted on 2017-04-12

This is a small maintenance release of the Connect2id server.

Summary:

  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.

Download

To download a ZIP package of Connect2id server 6.6.1:

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

(SHA-256: a8360793842a68aa3758682bf16b69a7bf1aac9f6ffb309b609a7518e922d549)

As WAR package only:

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

(SHA-256: 7dd33494e40a889cbcd4427117af1d08d4b28539a4402b916c62dff1b1fca739)

Questions?

Get in touch Connect2id support to receive assistance.


Release notes

6.6.1 (2017-04-12)

Configuration

  • No changes

Web API

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

Dependencies

  • 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

Nimbus JOSE+JWT 4.35 deprecates use of SHA-1 and RSA encryption with PKCS1v1.5 padding

Posted on 2017-04-10

Deprecates use of SHA-1

CWI and Google’s announcement of a practical technique for producing SHA-1 collisions served a wake-up call to the industry to finally commit to phasing out the 22 year old hash algorithm and move to the newer and more secure SHA-2 and SHA-3.

Today’s 4.35 release of the the Nimbus JOSE+JWT library encourages developers to do just that:

  • Use of the x5t certificate SHA-1 thumbprint parameter in JWS and JWE headers is deprecated now, use x5t#S256 (SHA-256) instead.

  • Use of the x5t certificate SHA-1 thumbprint parameter in JWK objects is also marked as deprecated, use x5t#S256 instead.

  • The RSA-OAEP JWE algorithm that uses SHA-1 as the hash function is deprecated, use RSA-OAEP-256 instead.

Deprecates use of RSA encryption with PKCS#1v1.5 padding

RSA encryption with PKCS#1v1.5 padding was another long-time candidate for phasing out, due to its timing attack vulnerability. Its RSA1_5 JWE algorithm identifier is marked as deprecated now. Developers should consider using RSA-OAEP-256 or the ECDH-ES family of JWE algorithms.


Release notes

version 4.35 (2017-04-09)

  • Adds support for JWK x5t#S256 header parameter (iss #205).
  • Deprecates use of RSA1_5 JWE algorithm as security measure to encourage use of RSA-OEAP-256 (iss #215).
  • Deprecates use of JWK x5t header parameter as part of security measure to move away from SHA-1 and encourage use of SHA-256 (iss #214).
  • Deprecates use of JWS and JWE x5t header parameter as part of security measure to move away from SHA-1 and encourage use of SHA-256 (iss #214).
  • Deprecates use of RSA-OAEP JWE algorithm as part of security measure to move away from SHA-1 and encourage use of SHA-256 (iss #214).
  • Upgraded JSON Smart dependency to support version range from 1.3.1 to 2.3.
  • Refines exception messages of DefaultJOSEProcessor and DefaultJWTProcessor.

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.