Connect2id server 7.17 updates access tokens and introspection

2019-10-12

Updated token introspection

Connect2id server 7.17 updates JWT-secured introspection responses to the latest OAuth version 08 draft. Signed introspections are useful for meeting assurance and legal requirements in applications dealing with verified person data, personal certificates and qualified electronic signatures. The changes are detailed in the release notes.

New type header explicitly identifies JWTs that are access tokens

This release also takes a first step in implementing the new OAuth draft for interoperable JWT-encoded access tokens. The spec defines a minimal set of standard JWT claims for OAuth 2.0 servers that issue self-contained access tokens. All JWT-encoded access tokens issued by the Connect2id server will now include the "at+jwt" type designation in the JWT header.

Example JWT header for an access token:

{
  "alg" : "RS256",
  "typ" : "at+jwt",
  "kid" : "AhXoh4fe"
}

The prompt parameter is supported in plain OAuth 2.0 authorisation requests

The optional prompt parameter in OpenID authentication requests enables relying parties to check if an end-user is already logged in and has previously provided consent. It can also be used to force re-authentication, re-consent or a change in the active user account at the IdP:

  • prompt=none -- To check if the end-user is logged in and has previously given consent to the specified scope values. This is typically done from a hidden iframe. On success the server will issue an ID and access token, without requiring any interaction from the user. If the prompt=none request cannot be fulfilled the server will return a login_required, consent_required or a general interaction_required error, indicating that the relying party should repeat the request, but this time allow for user interaction.

  • prompt=login -- To force the end-user to be re-authenticated.

  • prompt=consent -- To force the end-user to re-consent the specified scope values.

  • prompt=select_account -- To hint the IdP to present the end-user with an account selection menu (in case the user has multiple accounts with the IdP).

All prompt values save for none can be combined, e.g. prompt=login consent.

The prompt parameter can also be useful for plain OAuth 2.0 authorisation requests, especially the consent and select_account values. For that reason the Connect2id server will now support it for all authorisation requests.

Note that the id_token_hint parameter cannot be used in conjunction with prompt for a plain OAuth 2.0 authorisation request.

Maintenance updates

This release also updates over a dozen underlying modules and libraries to their latest stable versions.

Download

To download a ZIP package of Connect2id server 7.17:

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

SHA-256: 06417bab6594d37f34f5a4445bfe6bfa2bd14f077a71afbf38033849e561ef95

As WAR package only:

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

SHA-256: adb747202305c33758a268f7118685f2706d44dbdab132aa66cfbff1601b3ea7

Questions?

Contact Connect2id support.


Release notes

7.17 (2019-10-12)

General

  • Issues JWT-encoded access tokens will now include the JOSE header parameter type ("typ") set to "at+jwt". Applies to signed as well as nested (signed and encrypted) access tokens. This explicit marking of access tokens is intended to prevent potential confusion with other JWT types, such as OpenID tokens. See JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens (draft-ietf-oauth-access-token-jwt-02), section 2.1.

  • Updates support for JWT Response for OAuth Token Introspection to draft-ietf-oauth-jwt-introspection-response-08.

  • The OpenID "prompt" parameter is now also supported with plain OAuth 2.0 authorisation requests.

Web API

  • /token/introspect

    • Introspection responses now include the JWT ID ("jti") claim for identifier-based access token, set to the first 8 bytes of the SHA-256 hash of the token identifier value.

    • Applies audience restriction to introspected access tokens. If the access token is specified with an audience which doesn't match the caller (client_id), typically that of a resource server, it will be marked as invalid (active=false).

    • Minimises the reported audience of introspected access tokens. If the access token is specified with multiple audiences, of which one matches the caller (client_id), only the caller will be included in the "aud" parameter; any other values (client_id's of resource servers) will be omitted in the response.

    • JWT-secured responses now return JWTs with a type ("typ" header) set to "token-introspection+jwt".

    • JWT-secured responses now always include the issued-at ("iat") claim, set to the time when the response was issued, which will override any token "iat" claim.

    • JWT-secured responses now always include the JWT IT ("jti") claim, see above for details.

  • /authz-sessions/rest/v3/

    • The OpenID "prompt" parameter is now also supported with plain OAuth 2.0 authorisation requests. The prompt values "none", "login", "consent" and "select_account" will be handled identically to OpenID authentication requests. Note that the "id_token_hint" parameter cannot be used in conjunction with "prompt" for a plain OAuth 2.0 authorisation request.

Dependency changes

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

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

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

  • Updates to com.nimbusds:oidc-session-store:12.0.4

  • Updates to com.nimbusds:nimbus-jose-jwt:7.9

  • Updates to com.nimbusds:common:2.35

  • Updates Infinispan to 9.4.16.Final

  • Updates to com.nimbusds:infinispan-cachestore-redis:9.2.8

  • Updates to com.nimbusds:infinispan-cachestore-ldap:3.1.2

  • Updates to com.unboundid:unboundid-ldapsdk:4.0.12

  • Updates to com.nimbusds:infinispan-cachestore-sql:3.1.5

  • Updates to com.zaxxer:HikariCP:3.4.1

  • Updates to org.jooq:jooq:3.11.12

  • Updates to org.mariadb.jdbc:mariadb-java-client:2.4.4

  • Updates to com.h2database:h2:1.4.199

  • Updates to commons-codec:commons-codec:1.13

  • Updates to org.apache.commons:commons-collections4:4.4

  • Updates to commons-io:commons-io:2.6

  • Updates Dropwizard Metrics to 4.0.6

  • Updates Log4j to 2.12.1

Nimbus JOSE+JWT 7.9 fixes an unchecked exception vulnerability

2019-10-07

Nimbus JOSE+JWT 7.9 fixes vulnerabilities in the code which may result in the library throwing an unchecked Java exception on certain malformed JWT or JOSE input.

Uncaught exceptions (CWE-248) could result in a crash (potential information disclosure) or a potential authentication bypass, depending on how the library is integrated into an application.

Users are advised to upgrade.

The CVSSv3 score is 6.0 - CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:L/E:F/RL:O/RC:C.

The vulnerability was allocated CVE-2019-17195.

We thank the Oracle Cloud Infrastructure (OCI) Security Research Team and their member, Devin Cook, for the discovery and reporting.


Release notes

version 7.9 (2019-10-05)

  • Adds new static null-safe Base64.from(String) and Base64URL.from(String) methods.
  • Makes JWKSet and KeyUse serializable (iss #330).
  • Fixes NPE when parsing JOSE header with missing or null "alg" (iss #332). Allocated CVE-2019-17195.
  • Fixes IllegalArgumentException when parsing JOSE header with null "typ" (iss #333). Allocated CVE-2019-17195.
  • Fixes NPE when parsing JOSE header with null "crit" (iss #334). Allocated CVE-2019-17195.
  • Fixes NPE when parsing JOSE header with null "jwk" (iss #335). Allocated CVE-2019-17195.
  • Fixes NPE when parsing JOSE header with null BASE64 or BASE65URL encoded parameters (iss #336). Allocated CVE-2019-17195.
  • Fixes IllegalArgumentException when parsing JWE header with null "zip" (iss #337). Allocated CVE-2019-17195.
  • Catch unexpected exceptions in JSONObjectUtils.parse and rethrow as ParseException. Allocated CVE-2019-17195.

Connect2id server 7.16 with token introspection update

2019-09-09

This is a mini update to the Connect2id server which updates the token introspection endpoint to include the optional expiration ("exp") parameter in the response for identifier-based access tokens.

This update also fixes two issues. See the release notes below for more information.

Download

To download a ZIP package of Connect2id server 7.16:

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

SHA-256: b85b9fea360c38b2287c5f44559c9cc3092aa6bad6eec013504f824107659486

As WAR package only:

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

SHA-256: d3db91263ad1773fa475f1003ed3f53144629fb0983c3e0de1fea8396930a2d5

Questions?

Contact Connect2id support.


Release notes

7.16 (2019-09-09)

Web API

  • /token/introspect -- Includes the optional expiration (exp) parameter in introspection responses for identifier-based access tokens. See OAuth 2.0 Token Introspection (RFC 7662), section 2.2.

Resolved issues

  • Fixes a bug which resulted in a HTTP 500 error when reading an OAuth 2.0 client registration with an empty JWK set ("jwks") from DynamoDB (issue server/480).

  • Fixes a bug which affected setting of the "exp" and potentially other JWT claims in calls to the AccessTokenIssueEventListener SPI (issue authz-store/164).

Dependency changes

  • Updates to com.nimbusds:oauth2-authz-store:12.4

Connect2id server 7.15 has new FAPI features

2019-08-26

FAPI is a collection of OAuth 2.0 security profiles which were originally intended for fintech applications but can also be employed in other areas where you need strongly secured identity and access tokens. This 7.15 release of the Connect2id server brings several updates for providers that need to be FAPI compliant or want to maintain the highest possible security standard for OAuth and OpenID Connect.

X.509 certificates in server JWKs

An X.509 certificate chain included in a server RSA or EC key (as x5c JWK parameter) will now be exposed in the published public key at the jwks.json endpoint and in the x5c header parameter of JWTs signed with it (ID tokens, self-contained access tokens, etc).

The X.509 certificate chain allows OAuth 2.0 clients to perform PKIX validation of the published key and hence tokens signed with it. Note that the Connect2id server will not perform PKIX validation on a configured JWK if the key includes a certificate chain. Including an "x5c" header in a JWT can also easily multiply its size.

New configuration to make PKCE required for all OAuth 2.0 clients

PKCE is an OAuth 2.0 security enhancement that binds an issued authorisation code to the original authorisation request. It was initially meant to protect public clients that lack a credential to authenticate at the token endpoint from code interception attacks, but can benefit confidential clients as well.

FAPI has therefore made the use of PKCE a requirement. Unfortunately PKCE didn't specify a standard client registration parameter to allow this to be configured individually per OAuth 2.0 client. So we created a new global server configuration op.authz.requiredPKCE which, if set, lists the required code challenge methods (S256, plain) that all clients must use.

Check our PKCE guide for clients if you have a Java application.

The UserInfo endpoint no longer accepts access tokens in the URI query

Passing an access token in the URI query is a horrible practice as it may result in the token leaking through web server logs. To discourage clients from this the UserInfo endpoint of the Connect2id server will no longer accept tokens in the access_token query parameter.

Insecure submission of a bearer token in the URI query:

GET /userinfo?access_token=Toasu1haw8ithop7 HTTP/1.1
Host: c2id.com

The HTTP response will return a helpful error message explaining why the request was rejected:

HTTP/1.1 400 Bad Request
Content-Type: application/json

{
  "error"             : "invalid_request",
  "error_description" : "Invalid request: Access token disallowed in URI query"
}

Clients should instead pass the token in a Authorization header or in a access_token form-encoded body parameter.

If for some reason clients cannot transport the access token in the "Authorization" request header field or the HTTP request entity-body, the URI query method can be allowed with a new op.userinfo.allowAccessTokenInURIQuery configuration:

op.userinfo.allowAccessTokenInURIQuery = true

The Userinfo endpoint is now FAPI compliant

The UserInfo endpoint is now FAPI compliant, by normally disallowing tokens in the URI query and by also supporting the X-FAPI-Interaction-ID header. The header is intended to aid logging, auditing and support calls, by giving the resource request and the resulting response (success or error) a common unique identifier. If the client sets the header in the outgoing HTTP request the Connect2id server will echo it in the resulting HTTP response. The value should be an UUID.

GET /userinfo HTTP/1.1
Host: c2id.com
Authorization: Bearer Toasu1haw8ithop7
X-FAPI-Interaction-ID: 1ebc5b42-81cd-4a43-a668-c7383bfd61df

If the request header isn't set the Connect2id server will generate an UUID for the response.

New metrics gauge shows Connect2id server version

The Connect2id server version can now be found out from the metrics endpoint, by looking up the server.version gauge.

HTTP/1.1 200 Success
Cache-Control: must-revalidate,no-cache,no-store
Content-Type: application/json

{
  "version" : "3.0.0",
  "gauges"  : { "server.version" : { "value": "7.15" },
  ...
  }
  ...
}

Bug fixes

The new release also fixes several issues, details in the notes below.

Download

To download a ZIP package of Connect2id server 7.15:

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

SHA-256: 381366fdedc5524d20ba1b5d4f243a1e09e72c1558af8f5cfe07e441d7327853

As WAR package only:

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

SHA-256: 617a31748d6a66b822d05ebaed49f6e23597082019fc2b48f44596eb33c9787e

Questions?

Contact Connect2id support.


Release notes

7.15 (2019-08-26)

Configuration

  • /WEB-INF/jwkSet.json

    • Public RSA and EC JSON Web Keys (JWK) that specify an X.509 certificate chain ("x5c" parameter, see RFC 7517, section 4.7) will be published at the /jwks.json endpoint with the certificate chain included. Issued ID tokens and self-contained (JWT-encoded) access tokens that are signed with such a key will also include the certificate chain as the "x5c" JWT header parameter (see RFC 7515, section 4.1.6).

      The X.509 certificate chain allows OAuth 2.0 clients to perform PKIX validation of the published keys and the issued tokens. Note that the Connect2id server will not validate the certificate chains of configured server JWKs.

  • /WEB-INF/oidcProvider.properties

    • Adds new "op.authz.requiredPKCE" configuration property listing the required PKCE (RFC 7636) code challenge methods which OAuth 2.0 clients must use at the authorisation endpoint. The values are specified as a comma and / or space separated code challenge method names. If empty or not specified PKCE is not required. The default value is not required.

    • Adds new "op.userinfo.allowAccessTokenInURIQuery" configuration property for the UserInfo endpoint to allow access tokens submitted via the access_token URI query parameter. The default policy (false) now is to reject access tokens received via the URI query parameter in order to prevent potential token leakage via web server access logs. The URI query method should not be allowed unless it is impossible to transport the access token in the "Authorization" request header field or the HTTP request entity-body. See RFC 6750, section 2.3.

Web API

  • /userinfo

    • Makes the UserInfo endpoint FAPI profile compliant by logging and echoing the x-fapi-interaction-id HTTP request header. If the header is not set by the client the Connect2id server will generate an UUID value for it and return it in the UserInfo HTTP response.
  • /monitor/v1/metrics

    • Adds new "server.version" gauge of type string to indicate the Connect2id server version, e.g. "7.15".

Resolved issues

  • Skips validation of OpenID authentication request specific parameters, such as "claims", when processing a plain OAuth 2.0 request. Fixes an authorisation session serialisation bug that affected processing of plain OAuth 2.0 requests with custom parameters (issue server/479).

  • Fixes a concurrency issue in the session store introduced in v7.12.1 which may result in a deleted subject session after the session is read. Applies to stateless cluster deployments only (DynamoDB, Redis + MySQL / PostgreSQL) (issue session store/81).

  • Logs the exception message and PEM string when parsing an invalid client X.509 certificate. Fixes logging of a missing client certificate when the Connect2id server is behind an Apache HTTPd reverse proxy (issue server/475).

  • Logs subject session removal events under SS0213 (issue session store/81).

Dependency changes

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

  • Updates to com.nimbusds:oauth2-authz-store:12.1

  • Updates to com.nimbusds:oidc-session-store:12.0.3

  • Updates to com.thetransactioncompany:cors-filter:2.8

Connect2id server 7.14 supports encrypted request objects

2019-07-16

We are delighted to announce support for encrypted request objects (JARs) in Connect2id server 7.14.

1. Encrypted request objects

OAuth 2.0 clients and OpenID relying parties can now submit authorisation requests to the server which parameters are kept confidential from the browser and end-user. The authorisation requests can be directly encrypted with JSON Web Encryption (JWE), or after signing them with JWS.

1.1 JWE algorithms

The following standard JWE algorithms are supported:

  • RSA encryption with RSA-OAEP-256, RSA-OAEP and RSA1_5. Note that use of RSA-PKCS1 v1.5 is no longer recommended and RSA-OAEP-256 should be used instead of RSA-OAEP.

  • ECDH encryption with ECDH-ES, ECDH-ES+A128KW, ECDH-ES+A192KW and ECDH-ES+A256KW.

  • AES 128, 192 and 256 bit encryption (dir) with a symmetric key derived from the client secret.

Two new configuration properties were introduced to set the enabled JWE algorithms and content encryption methods:

If the two configuration properties aren't set the Connect2id server will not accept encrypted request objects.

1.2 Server JWK set

If you intend to support public key encrypted request objects update the server JWK set to include the required RSA and EC encryption keys.

The public encryption keys will be published together with the public signing keys (for JWT validation), so clients that intend to submit RSA or ECDH encrypted authorisation requests can download them.

The server JWK set generator was updated to support creation and rotation of RSA and EC (P-256, P-384 and P-521 curve) encryption keys (v1.9).

Example EC key pair with P-256 curve marked for encryption use:

{
  "kty" : "EC",
  "crv" : "P-256",
  "use" : "enc",
  "kid" : "1yFA",
  "x"   : "_-aKZeuwWDv4v89dPGdKtpOuOepc_0qDZDhcv3omzX0",
  "y"   : "Gc5b7muOqbi4QvYJO24a4IqQoOY1pPM69DcpI605Vmw",
  "d"   : "lFj2hl_0MDs7D3yyTgU6LedcJ7NUZAs6noGzhZszsRA"
}

If only direct (dir) AES encryption based on client secrets is going to be used there is no need to generate and publish public RSA and EC encryption keys.

1.3 Client registration

Clients that intend to use encrypted request objects should declare that in their registration. Clients may also submit encrypted requests without explicitly registering for that, however, the registration gives them the opportunity to have the JWE algorithm parameters checked by the server.

Example client registration for RSA-OAEP-256 public key encryption with A128GCM content encryption:

POST /c2id/clients HTTP/1.1
Host: demo.c2id.com
Content-Type: application/json
Authorization: Bearer ztucZS1ZyFKgh0tUEruUtiSTXhnexmd6

{
  "redirect_uris"                 : [ "https://client.example.org/callback" ],
  "jwks_uri"                      : "https://client.example.org/jwks.json",
  "request_object_encryption_alg" : "RSA-OAEP-256",
  "request_object_encryption_enc" : "A128GCM"
}

Example client registration for dir AES 128 bit encryption with a key derived from the client secret.

POST /c2id/clients HTTP/1.1
Host: demo.c2id.com
Content-Type: application/json
Authorization: Bearer ztucZS1ZyFKgh0tUEruUtiSTXhnexmd6

{
  "redirect_uris"                 : [ "https://client.example.org/callback" ],
  "jwks_uri"                      : "https://client.example.org/jwks.json",
  "request_object_encryption_alg" : "dir",
  "request_object_encryption_enc" : "A128GCM"
}

1.4 Making encrypted requests

In order to submit an encrypted request object the OAuth 2.0 client needs to download the server JWK set and extract a public encryption keys from it that matches the desired JWE algorithm.

The request parameters are then encoded as claims into a JWT which is encrypted.

The following example using the open source OAuth 2.0 / OpenID Connect SDK that we maintain for the community shows how to do that, starting from the OpenID provider URL to discover all necessary endpoints and parameters.

import java.net.URI;
import java.util.List;
import com.nimbusds.jose.*;
import com.nimbusds.jose.crypto.*;
import com.nimbusds.jose.jwk.*;
import com.nimbusds.jwt.*;
import com.nimbusds.oauth2.sdk.*;
import com.nimbusds.oauth2.sdk.client.*;
import com.nimbusds.oauth2.sdk.http.*;
import com.nimbusds.oauth2.sdk.id.*;
import com.nimbusds.oauth2.sdk.token.*;
import com.nimbusds.openid.connect.sdk.*;
import com.nimbusds.openid.connect.sdk.op.*;

// Need OP issuer URL and access token for the registration as minimum
Issuer opIssuer = new Issuer("https://demo.c2id.com/c2id");
BearerAccessToken regEndpointToken = new BearerAccessToken("ztucZS1ZyFKgh0tUEruUtiSTXhnexmd6");

// Download OpenID provider metadata and JWK set
OIDCProviderMetadata opMetadata = OIDCProviderMetadata.resolve(opIssuer);
JWKSet opJWKSet = JWKSet.load(opMetadata.getJWKSetURI().toURL());

// Will use RSA-OAEP-256 and A128GCM encryption
assert opMetadata.getRequestObjectJWEAlgs().contains(JWEAlgorithm.RSA_OAEP_256);
assert opMetadata.getRequestObjectJWEEncs().contains(EncryptionMethod.A128GCM);

// Register client
ClientMetadata clientMetadata = new ClientMetadata();
clientMetadata.setRedirectionURI(URI.create("https://example.com/cb"));
clientMetadata.setRequestObjectJWEAlg(JWEAlgorithm.RSA_OAEP_256);
clientMetadata.setRequestObjectJWEEnc(EncryptionMethod.A128GCM);
clientMetadata.applyDefaults();

HTTPResponse httpResponse = new ClientRegistrationRequest(
    opMetadata.getRegistrationEndpointURI(),
    clientMetadata,
    regEndpointToken)
    .toHTTPRequest()
    .send();

ClientRegistrationResponse regResponse = ClientRegistrationResponse.parse(httpResponse);

if (! regResponse.indicatesSuccess()) {
    System.err.println(regResponse.toErrorResponse().getErrorObject());
    return;
}

ClientInformation clientInfo = regResponse.toSuccessResponse().getClientInformation();

assert clientInfo.getMetadata().getRequestObjectJWEAlg().equals(JWEAlgorithm.RSA_OAEP_256);
assert clientInfo.getMetadata().getRequestObjectJWEEnc().equals(EncryptionMethod.A128GCM);

// Select public RSA encryption key from OP JWK set
List<JWK> rsaJWKs = new JWKSelector(new JWKMatcher.Builder()
    .keyType(KeyType.RSA)
    .keyUse(KeyUse.ENCRYPTION)
    .build())
    .select(opJWKSet);

if (rsaJWKs.isEmpty()) {
    System.err.println("No RSA encryption key(s) found in OP JWK set");
    return;
}

// Create encrypted OpenID auth request
RSAKey rsaJWK = (RSAKey)rsaJWKs.get(0); // use the first encryption key

EncryptedJWT jar = new EncryptedJWT(
    new JWEHeader.Builder(
        clientInfo.getMetadata().getRequestObjectJWEAlg(),
        clientInfo.getMetadata().getRequestObjectJWEEnc())
        .keyID(rsaJWK.getKeyID())
        .build(),
    new AuthenticationRequest.Builder(
        new ResponseType("code"),
        new Scope("openid"),
        clientInfo.getID(),
        clientInfo.getMetadata().getRedirectionURI())
        .state(new State())
        .build()
        .toJWTClaimsSet());
jar.encrypt(new RSAEncrypter(rsaJWK));

AuthenticationRequest authRequest = new AuthenticationRequest.Builder(jar)
    .endpointURI(opMetadata.getAuthorizationEndpointURI())
    .build();

// Output the OpenID auth request
System.out.println(authRequest.toURI());

Learn more about request objects and their use in our excellent article.

2. Other features

The Connect2id server SDK was updated to v4.5 and now exposes an additional method in the ClaimsSourceRequestContext to find out how the sourced OpenID claims are going to be delivered - at the UserInfo endpoint or included in the ID token.

3. Resolved issues

The 7.14 release fixes a number of bugs related to request object processing, also a significant bug that prevented correct loading of JWK sets configured via the "jose.jwkSet" Java system property. Deployments that use this method to configure the server keys (instead of the regular WEB-INF/jwkSet.json) should update to 7.14.

There is more information in the release notes below.

Download

To download a ZIP package of Connect2id server 7.14:

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

SHA-256: b4ce85678ee218e615aba0198d0d7649551887dcaa5a7f82e538f836caf3114a

As WAR package only:

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

SHA-256: c58b40906c6baa8e3369b2a7687fcbd02b20aedb4cabae64807984352db108e0

Questions?

Contact Connect2id support.


Release notes

7.14 (2019-07-15)

General

  • Support for encrypted (JWE) request objects passed with the optional OAuth 2.0 request or request_uri authorisation request parameter. Supported are RSA (RSA-OAEP-256, RSA-OAEP, RSA1_5) and ECDH (ECDH-ES, ECDH-ES+A128KW, ECDH-ES+A192KW, ECDH-ES+A256KW) public key encryption as well as shared key encryption (dir) with an AES key derived from the client's secret.

    Clients can obtain the public encryption keys (with use=enc) from the Connect2id server JWK set endpoint.

    Clients must include their client_id as top-level authorisation request parameter when submitting request objects encrypted with an AES key derived from the client's secret, to enable the Connect2id server to lookup the secret.

    The JWK set generator for the Connect2id server was updated to support public encryption keys, see https://bitbucket.org/connect2id/server-jwkset-gen

    Processing of encrypted request objects conforms with the "OpenID Connect 1.0" and "The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR)" (draft-ietf-oauth-jwsreq-19) specifications.

Configuration

  • /WEB-INF/jwkSet.json

    • Includes public RSA (2048 bit) and EC (P-256, P-384 and P-521) JSON Web Keys (JWK) with key use set to encryption (use=enc) for OAuth 2.0 clients to encrypt request objects to the Connect2id server. The presence of public encryption JWKs in the set is optional. Rotation is supported by prefixing new public encryption keys to the set (clients should use the first encryption key that matches the desired JWE algorithm).
  • /WEB-INF/oidcProvider.properties

    • op.authz.requestJWEAlgs -- New optional configuration property listing the accepted JWE algorithms for encrypted OAuth 2.0 authorisation requests passed with the optional request_uri or request parameter. The default value is none.

      The following standard JWE algorithms are supported:

      • RSA-OAEP-256
      • RSA-OAEP (use no longer recommended)
      • RSA1_5 (use no longer recommended)
      • ECDH-ES
      • ECDH-ES+A128KW
      • ECDH-ES+A192KW
      • ECDH-ES+A256KW
      • dir
    • op.authz.requestJWEEncs -- New optional configuration property listing the accepted JWE content encryption methods for encrypted OAuth 2.0 authorisation requests passed with the optional request_uri or request parameter. The default value is none.

      The following standard JWE methods are supported:

      • A128CBC-HS256
      • A192CBC-HS384
      • A256CBC-HS512
      • A128GCM
      • A192GCM
      • A256GCM

SPI

  • com.nimbusds.openid.connect.provider.spi.claims.AdvancedClaimsSource

    • Adds a new getClaimsTransport() method to the ClaimsSourceRequestContext to indicate how the OpenID claims are retrieved by the relying party. Returns "USERINFO" for the UserInfo endpoint, "ID_TOKEN" for including the claims in the issued ID token, and null if not applicable (the claims source SPI is invoked for another purpose, for example in a TokenEncoderContext).

Resolved issues

  • Fixes a bug which prevented loading of Connect2id server keys overridden or passed via the "jose.jwkSet" Java system property. Deployments that rely on loading the server JWK set via the "jose.jwkSet" Java system property must upgrade. The bug did not affect the multi-tenant Connect2id server edition (issue server/471).

  • OAuth 2.0 clients not explicitly registered for "request_object_signing_alg" must be able to use any supported JWS algorithm for signed request objects (JAR), provided the client has registered the necessary key material (public key or client secret) (issue server/469).

  • Remote JWK set (jwks_uri) sourcing errors when processing signed request objects should result in invalid_request_object error, not HTTP 500 (issue server/474).

  • When processing signed request objects a failed client JWK to Java key conversion should result in invalid_request_object error, not HTTP 500.

  • When serving UserInfo requests the "openid" scope value becomes required for the access tokens. Previously the UserInfo endpoint only checked that the access token permitted release of one or more OpenID claims. The OpenID scope values "profile", "email", "address" and "phone" will continue to be ignored in order to comply with data minimisation principles (issue server/473).

  • Updates the SQL DB connector to output a more detailed stack trace when parsing a corrupt JSON field in a SQL record.

Dependency changes

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

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

  • Updates to com.nimbusds:nimbus-jwkset-loader:4.2

  • Updates to com.nimbusds:oidc-session-store:12.0.1

  • Updates to com.nimbusds:infinispan-cachestore-sql:3.1.3