c2id.net subscribers receive easy access to the logs of their OpenID Connect / OAuth 2.0 servers

c2id.net admin panel

Hosted Connect2id server subscribers can now enjoy easy access to the logs of their servers, directly from the admin panel. This can come in handy when you need to troubleshoot an integration or why for instance a client application is failing to authenticate.

The admin panel provides access to the server logs from the past 72 hours.

If you are interested in a hosted Connect2id server, check out the offerings at c2id.net. As a subscriber you can choose an optimal AWS region to have your server instances deployed and all plans come with a 2+ node cluster to provide high-availability and load-balancing for your OAuth and OpenID Connect applications.

Connect2id server 12.10

This release of the Connect2id server introduces support for OpenID authentication requests with prompt=create, implements explicitly typed logout tokens and updates the AWS region selection in the DynamoDB connector.

Applications requesting a sign-up screen with prompt=create

The OpenID Connect working group adopted a new spec that defines a new value for the prompt parameter, called create, to let relying parties request the OpenID provider to present the end-user with a sign-up screen as part of the authentication flow.

https://server.example.com/authorize?
 response_type=code
 &scope=openid
 &client_id=123
 &state=af0ifjsldkj
 &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
 &prompt=create

Requests with a prompt=create parameter will cause the Connect2id server to send the login handler an auth prompt message (even if the user is currently authenticated and has a valid session), with the create_account field set to true. This flag can be taken as signal to present the user with a sign-up screen.

If the OpenID provider has no requirement or wish to honour prompt=create requests the login handler can safely ignore the create_account flag and render the usual user authentication screen.

After the user is successfully registered the flow should proceed as usual.

Support for the create prompt value is advertised in the OpenID provider metadata, under prompt_values_supported. This metadata field lists the other standard prompt values defined in OpenID Connect Core and already supported by the Connect2id server: none, login, consent and select_account.

Example:

{
  "issuer"                  : "https://c2id.com",
  "prompt_values_supported" : [ "none", "login", "consent", "create" ],
  ...
}

You can find more information about the prompt=create in the spec and the release notes below.

Explicitly typed logout tokens

As you learned in the announcement of the last Connect2id server release, the explicit typing of JWTs is good for security and the OpenID Connect working group recently took the step to update the back-channel logout spec to define an optional logout+jwt type header for the logout tokens.

Starting with this release the Connect2id server will type all issued logout tokens with the logout+jwt header, unless it's configured to disable their typing for legacy reasons.

op.logout.backChannel.jwtTypeExplicit=true

If you have OpenID relying parties that use our Java SDK to deal with back-channel logout notification tokens check out the updated examples.

AWS region configuration for DynamoDB

The DynamoDB connector received an update to enable deployments to fall back to the default AWS region provider chain. This can be useful in deployments based on the AWS EKS where the AWS access credential is a web token obtained from a regional AWS STS endpoint.

If you are using DynamoDB and don't have any issues with the region selection, you can update to this Connect2id server release, keeping your existing configuration just as it is.

To take advantage of the default AWS region provider chain check out the DynamoDB connector configuration docs and the release notes.

Download 12.10

For the signature validation: Public GPG key

Standard Connect2id server edition

Apache Tomcat package with Connect2id server 12.10: Connect2id-server.zip

GPG signature: Connect2id-server.zip.asc

SHA-256: 97d8f6cc1bcb0e237b6e4936f49457142fb9496ddd81a260872992e90133fb9a

Connect2id server 12.10 WAR package: c2id.war

GPG signature: c2id.war.asc

SHA-256: fdc9e2a02d0bc7f3360362bc16625223e1c27fbdcdbeccc75c7945c4bdf6b095

Multi-tenant edition

Apache Tomcat package with Connect2id server 12.10: Connect2id-server-mt.zip

GPG signature: Connect2id-server-mt.zip.asc

SHA-256: 756301ca6269599d2f89e6ff72d7dead39360d36e7c38f4d0d3db453c207c600

Connect2id server 12.10 WAR package: c2id-multi-tenant.war

GPG signature: c2id-multi-tenant.war.asc

SHA-256: 4a6a12104a5b55ccb9f47129ab57dd581629ef33a842849f7b1a3395f8c7fdf8

Questions?

If you have technical questions about this new release contact Connect2id support. To purchase a production license for the Connect2id server, renew or upgrade your support and updates subscription, email our sales.


Release notes

12.10 (2022-05-03)

Summary

  • Support for OpenID authentication requests with prompt=create to enable relying parties to instruct the OpenID provider to present the user with a sign-up screen. After the user is successfully registered the flow proceeds as usual. Support for the "create" prompt value is advertised in a new "prompt_values_supported" OpenID provider metadata field. Login handlers integrating with the authorisation session API will receive indication of a prompt=create in a new "create_account" {true|false} parameter of the "auth" message. If the OpenID provider has no requirement or wish to honour prompt=create the login handler can safely ignore the "create_account" flag and render the usual user authentication screen. OpenID prompt=create requests will always trigger an "auth" prompt message in the authorisation session API, similarly to OpenID prompt=select requests.

    The Connect2id server will reject OpenID authentication requests with a prompt parameter that contains values other than "create", in accordance with the specification recommendation.

    This new prompt "create" value is specified in Initiating User Registration via OpenID Connect - draft 04, see https://openid.net/ specs/openid-connect-prompt-create-1_0.html

  • Support for minting back-channel logout notification tokens with explicit JWT typing. This is a simple measure to help relying parties simplify the prevention of mix-up of logout token JWTs with other types of JWT without having to examine the JWT claims structure. Enabled by default.

Configuration

  • /WEB-INF/oidcProvider.properties

    • op.logout.backChannel.jwtTypeExplicit -- New configuration property to enable / disable explicit typing of the issued back-channel logout tokens by setting the JWT type ("typ") header to "logout+jwt". Explicit logout token typing is a new recommendation in OpenID Connect Back-Channel Logout 1.0 - draft 07, section 4.1. This is a simple measure to prevent mix-up of logout token JWTs with other types of JWT without having to examine the JWT claims structure. Enabled by default.

      See https://openid.net/specs/openid-connect-backchannel-1_0.html

  • /WEB-INF/infinispan-*-dynamodb.xml

    • Removes the default "dynamodb.region" setting of "us-east-1". The purpose of this change is to enable DynamoDB configurations where the AWS region is determined by the default AWS region provider chain, for example by setting the "AWS_REGION" environment variable. The DynamoDB store XML schema is updated to v1.19. See https://docs.aws.amazon.com/ sdk-for-java/v1/developer-guide/java-dg-region-selection.html

Web API

  • /.well-known/openid-configuration

    • prompt_values_supported -- New metadata field defined in Initiating User Registration via OpenID Connect - draft 04. Lists the supported prompt values in OpenID authentication requests. The Connect2id server supports the following prompt values: none, login, consent, select_account and create.
  • /authz-sessions/rest/v3/

    • The authentication prompt (message with type "auth") receives a new "create_account" member of type boolean to indicate an OpenID authentication request with a prompt=create parameter.

Resolved issues

  • Sourcing of "access_token:*" claims must call the AdvancedClaimsSource SPI instead of the basic ClaimsSource SPI in order to pass optional "claims_data" (issue server/753, authz-store/191).

Dependency changes

  • Updates to com.nimbusds:c2id-server-sdk:4.43

  • Updates to com.nimbusds:oauth2-oidc-sdk:9.35

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

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

  • Updates to com.nimbusds:oidc-claims-source-ldap:1.6.1

  • Updates to com.nimbusds:infinispan-cachestore-dynamodb:4.2

  • Updates to com.amazonaws:aws-java-sdk-dynamodb:1.12.201

  • Updates to com.nimbusds:c2id-server-property-source:1.0.4

  • Updates to org.postgresql:postgresql:42.3.4

  • Updates to org.slf4j:slf4j-api:1.7.36

  • Updates to com.github.dubasdey:log4j2-jsonevent-layout:0.0.7

  • Updates to com.nimbusds:token-event-publisher-aws-sqs:1.1.3

  • Adds dependency to com.amazonaws:aws-java-sdk-sts:1.12.201

The Java ECDSA cryptography CVE-2022-21449 - are you affected and what to do?

Update 2022-04-22: The Nimbus JOSE+JWT library was not able to block all CVE-2022-21449 vectors of attack on vulnerable Java 15+ runtimes where the default Java ECDSA was targeted. This post is corrected to reflect this. We apologise for the incorrect initial assessment published here.

CVE-2022-21449 is a severe security bug in the standard Java Cryptography Architecture (JCA) provider that allows shockingly trivial bypassing of ECDSA signature validation in Java 15 and later. Neil Madden, who you may know from his contributions in the JOSE, OAuth and OpenID working groups, discovered the issue in November 2021 and has a detailed description of it in his blog, in a post published on 19 April 2022 when Oracle released a fix.

Are you affected?

  • Applications that use the Nimbus JOSE+JWT library to process ES256, ES384 and ES512 JWS signatures on Java 15 or newer runtimes prior to the Oracle fix and using the default Java Cryptography Architecture (JCA) provider that comes in the JRE were not safe from CVE-2022-21449 exploits.

    Previously it was thought that the P1363 to DER transcoder for the ECDSA signatures was blocking all exploitable values from reaching a vulnerable Java ECDSA provider, but this was true only for the case of zero R and S signature values.

  • The Nimbus JOSE+JWT library borrowed the P1363 to DER transcoding logic from the Apache Santuario library (code link). This means that other projects that borrowed this code or rely on it, like OpenSAML, are also not immune and cannot rely on the particular transcoder implementation to block attacks on Java runtimes vulnerable to CVE-2022-21449.

  • You are not affected if you process ECDSA signatures in Java 14 or earlier (the bug was introduced in Java 15, after a rewrite from C++ to Java code).

  • You are not affected if you process ECDSA signatures with the open source BouncyCastle JCA provider (instead of the built-in Java JCA provider), regardless of the Java runtime version.

What to do?

  1. Upgrade to the latest patched Java version, even if you are not affected by CVE-2022-21449, because the Oracle Critical Patch Update from April addresses a number of other issues as well.

  2. We also strongly recommend to update to the latest patched Nimbus JOSE+JWT 9.22:

    <dependency>
       <groupId>com.nimbusds</groupId>
       <artifactId>nimbus-jose-jwt</artifactId>
       <version>9.22</version>
    </dependency>
    

If you cannot do any or both of these updates, for whatever reason, switch to the BouncyCastle provider for ECDSA signatures validation.

How trivial is the expoit?

See for yourself:


KeyPair keyPair = KeyPairGenerator.getInstance("EC").generateKeyPair(); byte[] blankSignature = new byte[64]; Signature sig = Signature.getInstance("SHA256WithECDSAInP1363Format"); sig.initVerify(keyPair.getPublic()); sig.update("Hello, world!".getBytes()); boolean validSig = signature.verify(blankSignature); assertFalse("Signature validation bypassed - upgrade your JRE with patched version for CVE-2022-21449", validSig);

Connect2id server 12.9 enables explicitly typed ID tokens and UserInfo JWTs

This release of the Connect2id server arrives with support for explicitly typed OpenID Connect tokens and a new client metadata parameter to simplify refreshing of client secrets.

Explicitly typed ID tokens and UserInfo JWTs

Applications that deal with JSON Web Tokens (JWT) meant for different purposes can potentially become vulnerable to accidental mix ups of JWTs and even to attacks that try to pass one type of JWT for another. The claims structure of JWTs minted for different purposes would normally differ, however not all JWT consuming logic may be robust enough to do this correctly and this may become a security issue.

To prevent such mix ups the JSON Web Token standard (RFC 7519) defines an optional "typ" (type) header parameter to give the JWT an explicit type. Consuming logic needs only to probe this header to find out the JWT purpose, without resorting to further analysis of the claims in the JWT payload.

OpenID Connect does not specify an explicit type for ID tokens and for signed UserInfo responses, relying on the fact that their claims sets differ substantially. Clients also obtain them at different endpoints - ID tokens at the token endpoint and signed UserInfo responses at the UserInfo endpoint.

Example ID token claims set:

{
  "iss"   : "https://c2id.com",
  "aud"   : "123",
  "sub"   : "alice",
  "iat"   : 1648547159,
  "exp"   : 1648547759
}

Example UserInfo JWT claims set:

{
  "iss"   : "https://c2id.com",
  "aud"   : "123",
  "sub"   : "alice",
  "iat"   : 1648547159,
  "email" : "[email protected]"
}

Notice how the ID token differs only by the presence of the "exp" (expiration) claim (the email UserInfo claim is optional).

In scenarios like token exchange the lack of explicit typing can however turn into an issue. That's why more recent specifications coming out of the the OAuth working group and the OpenID Foundation started making use of the explicit JWT typing. For example, at+jwt for access tokens compliant with RFC 9068.

In this new release Connect2id server deployments will be able to set explicit type headers for the ID tokens and UserInfo JWTs. This is made possible by two new configuration properties:

  • op.idToken.jwtType -- Sets the type header of issued ID tokens, if set the recommended value is id_token+jwt. Disabled by default.
  • op.userinfo.jwtType -- Set the type header of issued UserInfo JWTs, if set the recommended value is userinfo+jwt. Disabled by default.

A future release of the Connect2id server will also add support for typed back-channel logout tokens.

Sample ID token without explicit typing:

  • JWS Header:

    {
       "kid" : "CXup",
       "alg" : "RS256"
    }
    
  • Claims:

    {
       "iss"   : "https://c2id.com",
       "aud"   : "123",
       "sub"   : "alice",
       "iat"   : 1648547159,
       "exp"   : 1648547759
    }
    

Sample ID token with explicit typing (note the id_token+jwt header):

  • JWS Header:

    {
       "kid" : "CXup",
       "alg" : "RS256",
       "typ" : "id_token+jwt"
    }
    
  • Claims:

    {
       "iss"   : "https://c2id.com",
       "aud"   : "123",
       "sub"   : "alice",
       "iat"   : 1648547159,
       "exp"   : 1648547759
    }
    

The IDTokenValidator was updated in v9.32 of the OAuth 2.0 / OpenID Connect SDK to support explicitly typed ID tokens. Note, since this is a non-standard feature, other libraries may not be able to observe the "typ" header or may simply reject explicitly typed ID tokens.

New client metadata parameter to simplify secret refresh

The standard method to refresh a client's secret is to make a PUT request to the client's registration resource. If the client secret has expired or the server is configured to always refresh the secret on client update the response will include a newly generated secret. In case those conditions aren't met the client can now use a refresh_client_secret metadata field to explicitly signal its intent and receive a new secret.

Example client update request, showing use of the new refresh_client_secret metadata field:

PUT /clients/s6BhdRkqt3 HTTP/1.1
Authorization: Bearer SQvs1wv1NcAgsZomWWif0d9SDO0GKHYrUN6YR0ocmN0
Content-Type: application/json

{
  "client_id"             : "s6BhdRkqt3",
  "redirect_uris"         : [ "https://client.example.org/cb" ],
  "client_name"           : "My App",
  "refresh_client_secret" : true
}

For simplicity our recommendation is to always use the refresh_client_secret whenever a client secret refresh is desired.

The old secret will remain usable for a period of 30 minutes, to enable a seamless rollover to the new one, avoiding client interruption or temporary client authentication failures.

The OAuth 2.0 client authentication guide was updated to describe this new feature.

Operation of client secret codec plugins is not affected by the new refresh_client_secret metadata field and they will continue to work as before.

Download 12.9

For the signature validation: Public GPG key

Standard Connect2id server edition

Apache Tomcat package with Connect2id server 12.9: Connect2id-server.zip

GPG signature: Connect2id-server.zip.asc

SHA-256: d79e79a829817a52202efc27399f0c50c7ceda5322ec00863be98248017ea97e

Connect2id server 12.9 WAR package: c2id.war

GPG signature: c2id.war.asc

SHA-256: 5f87b6cf5a140891ade20e57acf8b2140b06c7a65b4063f4a7a24fe2572eecfe

Multi-tenant edition

Apache Tomcat package with Connect2id server 12.9: Connect2id-server-mt.zip

GPG signature: Connect2id-server-mt.zip.asc

SHA-256: 435b90170d61896598a61baa43fddb970aa0a3c390b98702018c17b201de757d

Connect2id server 12.9 WAR package: c2id-multi-tenant.war

GPG signature: c2id-multi-tenant.war.asc

SHA-256: 0022ce97081e2054aa2e389358f043a82f1d4db2e39f6e2621590e4b4abe7059

Questions?

If you have technical questions about this new release contact Connect2id support. To purchase a production license for the Connect2id server, renew or upgrade your support and updates subscription, email our sales.


Release notes

12.9 (2022-03-23)

Configuration

  • /WEB-INF/oidcProvider.properties

    • op.token.idToken.jwtType -- New configuration property to set the type ("typ") header of issued ID tokens. Explicit JWT typing is a simple measure to prevent mix-up of ID tokens JWTs with other types of JWT without having to examine the JWT claims structure. Note this is a non-standard feature and may result in rejection of ID tokens by client libraries not able or not configured to handle typing. Typing is disabled by default.

    • op.token.userinfo.jwtType -- New configuration property to set the type ("typ") header of issued UserInfo JWTs. Explicit JWT typing is a simple measure to prevent mix-up of UserInfo JWTs with other types of JWT without having to examine the JWT claims structure. Note this is a non-standard feature and may result in rejection of UserInfo JWTs by client libraries not able or not configured to handle typing. Typing is disabled by default.

Web API

  • /clients/

    • Adds support for a new optional "refresh_client_secret" client metadata field of type boolean for use in client update requests. When the "refresh_client_secret" is set to true in a client update request the Connect2id server will refresh the client secret, overriding a disabled op.reg.alwaysRefreshClientSecretOnUpdate configuration setting. When "refresh_client_secret" is set to false or omitted the refresh of the client secret will be determined by the configured op.reg. alwaysRefreshClientSecretOnUpdate setting.

      The intent of "refresh_client_secret" is to give registered clients a direct control over how soon or often to refresh their secret. This is a non-standard metadata field.

Dependency changes

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

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

  • Updates to com.nimbusds:lang-tag:1.6

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

  • Updates to org.postgresql:postgresql:42.3.3

Connect2id server 12.8

This is a mini plugin interface (SPI) and maintenance / security update of the Connect2id server for OpenID Connect identity provisioning and OAuth 2.0 authorisation.

  • The PAR validator SPI and the authorisation request validator SPI let plugins access the original raw requests, for purposes such as inspecting the presence of a signed request object (JAR).

    Example check for signed JAR presence:

    boolean jarPresent = validatorContext.getRawRequest()
        .specifiesRequestObject();
    JWSAlgorithm jwsAlg = validatorContext.getOIDCClientInformation()
        .getMetadata()
        .getRequestObjectJWSAlg();
    if (jarPresent && jwsAlg != null && JWSAlgorithm.Family.SIGNATURE.contains(jwsAlg)) {
        // Detected signed request
    }
    
  • Minor vulnerability and bug fixes. Upgrading is generally recommended.

  • Selected library updates.

Detailed information is available in the release notes below.

Download 12.8

For the signature validation: Public GPG key

Standard Connect2id server edition

Apache Tomcat package with Connect2id server 12.8: Connect2id-server.zip

GPG signature: Connect2id-server.zip.asc

SHA-256: 8fe22c0494af181be220ff73cc24d65e7b0fa4b5acd389efc9cf1f08b748aff6

Connect2id server 12.8 WAR package: c2id.war

GPG signature: c2id.war.asc

SHA-256: dd427ec8c873825537ab966e17e06e9be6a3f037d2e442965d418898cde503ed

Multi-tenant edition

Apache Tomcat package with Connect2id server 12.8: Connect2id-server-mt.zip

GPG signature: Connect2id-server-mt.zip.asc

SHA-256: 4587ec28a84b1ce0853430d594afe3d9911523127d2b1d8b077abebf73e12c52

Connect2id server 12.8 WAR package: c2id-multi-tenant.war

GPG signature: c2id-multi-tenant.war.asc

SHA-256: 42582f3e352d2d5e726e976faadaffba33cd35d5058aed2fe8a59dad9736b65f

Questions?

Contact Connect2id support.


Release notes

12.8 (2022-03-12)

SPI

  • Upgrades the Connect2id server SDK to com.nimbusds:c2id-server-sdk:4.42

    • com.nimbusds.openid.connect.provider.spi.par.ValidatorContext -- Adds new getRawRequest method returning the original raw OAuth 2.0 authorisation / OpenID authentication request, as received at the authorisation endpoint and prior to any JAR unwrapping / resolution if JWT-secured.

    • com.nimbusds.openid.connect.provider.spi.authz.ValidatorContext -- Adds new getRawRequest method returning the original raw OAuth 2.0 authorisation / OpenID authentication request, as received at the authorisation endpoint and prior to any JAR unwrapping / resolution if JWT-secured.

Resolved issues

  • Fixes a vulnerability in the Connect2id server banner (splash) page that allowed injection of HTML or JavaScript via an invalid "Issuer" HTTP header. No feasible exploits found, but upgrading is generally recommended. The banner page also receives a Content-Security-Policy to allow only local content (issue server/733).

  • Fixes a vulnerability at the token endpoint that allowed log injection of CR and LF characters via a client_id prior to client validation. In Connect2id server deployments with a plain text Log4j appender the vulnerability may be exploited to compromise the integrity of the log messages. The severity of the vulnerability is deemed low, upgrading is recommended (issue server/734).

  • Fixes the log label for the token introspection HTTP request logging and the OP6500 internal server error message (issue server/735).

  • The token and UserInfo endpoints must return an HTTP 400 Bad Request with an invalid_dpop_proof error when receiving a DPoP HTTP request header with a header value that doesn't parse to a signed JWT. Previously the Connect2id server ignored th DPoP header when JWT parsing failed (issue server/736).

Dependency changes

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

  • Updates to com.nimbusds:oauth2-oidc-sdk:9.28

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

  • Updates to com.nimbusds:common:2.48

  • Updates to org.cryptomator:siv-mode:1.4.4

  • Updates to net.minidev:json-smart:2.4.8