The OAuth 2.0 token exchange in Connect2id server 13.3 supports refresh token and ID token issue

2023-01-24

Connect2id server deployments with OAuth 2.0 token exchange (RFC 8693) will now be able to issue refresh tokens and ID tokens. Previously the token exchange plugin interface (SPI) was capable of only specifying access token issue. The persistence of the token exchange authorisation can also be controlled now, by setting its long-lived flag (which also determines when a refresh token gets issued whether it's going to be persisted, with long-lived set to true, or a stateless encrypted JWT, with long-lived set to false.

This token exchange upgrade makes it possible for Connect2id server deployments to experiment with the new OpenID Connect draft specification for native single sign-on (SSO) for Android, iOS and desktop applications. Built-in support for the native SSO is now on the Connect2id server roadmap and it will appear once the spec has become stable.

The new token exchange plugin capabilities can be found useful in other scenarios where a client needs to exchange a token of some kind (opaque or JWT) for a local Connect2id server issued access / refresh / ID token.

This release fixes two issues:

  • If you have clients using symmetrically encrypted ID tokens or UserInfo (by means of deriving a shared AES key from the client_secret) upgrading is strongly recommended, to ensure interoperability and correctness of the key derivation. The key derivation suffered from a poorly worded specification in OpenID Connect Core 1.0, addressed in a recent errata. The security of the encryption was never compromised, but depending on how the original spec was interpreted the decryption of JWE objects can unexpectedly fail with a different client library or OpenID Connect server.

    The key derivation issue was also fixed in v10.5.1 of the open source OAuth 2.0 / OpenID Connect SDK we maintain.

  • If you have a deployment with OpenID Connect Federation 1.0 upgrading is also suggested, so you can read the registrations of automatic clients via the clients API without entity URL encoding issues.

There is more information in the release notes.

Download 13.3

For the signature validation: Public GPG key

Standard Connect2id server edition

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

GPG signature: Connect2id-server.zip.asc

SHA-256: b503e2a247bb7bbe224f3f6ed3b7f0f27930edb50b501b1931ecc45173c99705

Connect2id server 13.3 WAR package: c2id.war

GPG signature: c2id.war.asc

SHA-256: d10fccf8fb49a5095ce7a387728ecdebe0023c6fd2411f264567c25741296a49

Multi-tenant edition

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

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

SHA-256: cce4e3dad989af9db16fca3ec8e731be913066ce59f41a099e5f0e9e47cc5197

Connect2id server 13.3 WAR package: c2id-mt.war

GPG signature: c2id-mt.war.asc

SHA-256: bf5f9b7a7fa6a3d80fde32c3405fdfbb61d8d8095b9bd4d71703cc84fbe42377

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

13.3 (2023-01-23)

Summary

  • Token exchange (RFC 8693) plugins can now optionally specify the issue of a refresh token and ID token (in addition to the access token) when authorising a request received via the TokenExchangeGrantHandler SPI. The plugin can also flag the authorisation as long-lived (persisted), to cause the granted scope values and other attributes to be remembered for the subject and the requesting client. This also enables control of the refresh token encoding (if issued) - persisted or stateless.

  • Resource owner password credentials grant plugins can now specify the issue of stateless (JWT-encoded) refresh tokens. Previously only persisted refresh tokens could be issued.

  • Updates the plugin for handling OAuth 2.0 grants at an external web service (web hook) to support token exchange (RFC 8693) authorisations for refresh token and ID token issue.

Web API

  • /token

    • Adds support for refresh token and ID token issue for a OAuth 2.0 token exchange grant (RFC 8693).

SPI

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

    • The TokenExchangeAuthorization class is updated to support optional persistence of the authorisation (with the long-lived flag), issue of a refresh token (stateless or persisted) and issue of an ID token.

    • The PasswordGrantAuthorization class is updated to support issue of a stateless refresh token when the long-lived authorisation flag is set to false. Previously only persisted refresh tokens could only be issued, when the long-lived authorisation flag was set to true.

Resolved issues

  • The AES key from client_secret derivation for shared JSON Web Encryption (JWE) of ID tokens, UserInfo responses and other objects must remove the right-most bits, not the left-most. See OpenID Connect Core 1.0 errata 2020-07-24 (issue oidc-sdk/412).

  • The clients web API GET by client_id must handle client identifiers that are OpenID Connect Federation 1.0 entity IDs (and URLs in general) seamlessly (issue server/824).

Dependency changes

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

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

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

  • Updates to com.nimbusds:oauth-grant-handlers-web:1.0.4

Connect2id server 13.2.1

2023-01-19

This is a maintenance release of the Connect2id server.

Should I upgrade?

An upgrade to 13.2.1 is recommended if:

  • You have a deployment with a plugin for handling SAML 2.0 assertion grants. This special OAuth 2.0 grant type is used to let client applications exchange a SAML 2.0 assertion for an OAuth 2.0 access token (potentially including a refresh token as well). Prior versions of the Connect2id server contain a dependency in the XML parsing stack reported vulnerable to CVE-2022-40152. A malicious SAML assertion which triggers the vulnerability will cause an internal stack overflow exception and the token endpoint returning an HTTP 500 Internal Server Error instead of a proper HTTP 400 Bad Request response with an invalid_grant error.

  • You have a deployment enabled for OpenID Connect Federation 1.0. This release fixes two bugs that affect the clean up of expired federation clients.

In all other cases upgrading is not necessary.

There is more information in the release notes below.

Native SSO for Android and iOS apps

A new specification in development at the OpenID Connect working group is now on the Connect2id server roadmap for 2023.

A mobile app which signs-in a user with OpenID Connect to obtain an ID token will be able to share the user identity with apps belonging to the same vendor:

  • A mobile app by a vendor is installed and the user logs in with OpenID Connect.

  • If the user chooses to install other apps belonging to the same vendor she will be automatically signed into them, a concept called "native SSO".

We are currently also discussing possibilities for mobile apps to seamlessly sign-in the user with trusted web applications and sites. This scenario can occur when the app opens a link to a web site of the vendor. The aim is to save the user from having to perform an additional web-based SSO with the Connect2id server and improve the overall UX when moving between mobile app and web site.

If you have comments, suggestions or wish to try out this feature before it is finalised write to Connect2id support.

LDAP backend support will be removed in 2023

We would also like to inform you that LDAP backend support will be removed in 2023, with version 13.x likely remaining the last one to have it. If you use an LDAP directory server to persist Connect2id server data consider migrating to a different database. This change does not affect the Connect2id server connector for sourcing OpenID claims from LDAP directories, which will remain available and supported.

2023 will also see official support for Java 17, to enable Connect2id servers to be deployed with the newer Java 17 runtime (while keeping the software Java 11 compatible).

Download 13.2.1

For the signature validation: Public GPG key

Standard Connect2id server edition

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

GPG signature: Connect2id-server.zip.asc

SHA-256: 889853c37a402ed36b04f29ec7962ee866800383ae59e6951e17ee8ee0f7d038

Connect2id server 13.2.1 WAR package: c2id.war

GPG signature: c2id.war.asc

SHA-256: be1785b7eb1f73d53c65a897617bfb9ff5dc2170e255ee17b2733da28672d276

Multi-tenant edition

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

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

SHA-256: 39ae9507bf51ef3e3baaa8ea12f251976ab8cd82da2b0c2b0bf57db9f80ad2cf

Connect2id server 13.2.1 WAR package: c2id-mt.war

GPG signature: c2id-mt.war.asc

SHA-256: 3b7c9fdce414cd20b097bcee8fac70014cecb4b70ce99efe59a06032602f2179

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

13.2.1 (2023-01-19)

Resolved issues

  • Updates the Woodstox Core dependency used in the SAML 2.0 assertion grant SPI, to address a potential stack overflow vulnerability in the XML DTD parse code (CVE-2022-40152). Note that the CVE has been incorrectly filed to an XStream dependency (a different project). Connect2id server deployments that don't use a SAML 2.0 assertion grant plugin for exchanging SAML 2.0 tokens for OAuth 2.0 tokens are not affected (issue server/820).

  • Streaming registered OpenID Connect Federation 1.0 clients from the federation client index must observe the tenant ID (issue server/640).

  • Fixes NPE that prevented clean up of expired OpenID Connect Federation 1.0 automatic clients (issue server/657).

Dependency changes

  • Updates to com.fasterxml.woodstox:woodstox-core:5.4.0

  • Updates Dropwizard Metrics to 4.2.15

Connect2id server 13.2 adds a signed JWKs endpoint for use in OpenID federations

2023-01-12

This release of the Connect2id server builds upon the OpenID Connect Federation 1.0 upgrade that arrived in 13.1 by adding a new signed JWKs endpoint. The signature establishes a digital proof that a server owns its OpenID provider keys, which proof then becomes linked to the server's trust chain in a federation.

The signed OpenID provider JWKs endpoint does not play an actual part in the trust resolution protocol defined in OpenID Connect Federation 1.0. The terms and policies that govern a particular federation may however require it, for non-repudiation and legal purposes. The Italian eID federation requires members to sign their public OpenID provider keys so that end-user authentication events (represented by issued ID tokens) can be linked to the trust chain in a verifiable manner. The Italian federation operator also has a policy to keep a historical archive of the keys of all members, in case disputes over past transactions arise.

Example request to retrieve the server's OpenID provider keys in a signed form:

GET /jwks.jwt HTTP/1.1
Host: demo.c2id.com

The response will be a signed JWT, carrying a keys claim that is a standard JWK set:

HTTP/1.1 200 OK
Content-Type: application/jwk-set+jwt

eyJraWQiOiJleFI1IiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiJodHRwczpcL1wvZmFwaS5jMmlkLmNv
bSIsIm1ldGFkYXRhIjp7Im9wZW5pZF9wcm92aWRlciI6eyJyZXF1ZXN0X3BhcmFtZXRlcl9zdXBwb3J
ZW5kcG9pbnQiOiJodHRwczpcL1wvZmFwaS5jMmlkLmNvbVwvdG9rZW5cL2ludHJvc3BlY3QiLCJj...

Note that the new signed JWK set endpoint will normally return an HTTP 404 Not Found status code, unless OpenID Connect federation is enabled.

This release also fixes two major bugs introduced in Connect2id server 13.0. Upgrading to 13.2 is strongly recommended if you are currently using an affected 13.0 or 13.1 deployment.

There is more information in the release notes below.

Download 13.2

For the signature validation: Public GPG key

Standard Connect2id server edition

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

GPG signature: Connect2id-server.zip.asc

SHA-256: 5676fd128a46fbdc113b4b6ffc930ddb636217a715e599356279ffa0f1171b64

Connect2id server 13.2 WAR package: c2id.war

GPG signature: c2id.war.asc

SHA-256: ed815c1404898266ea35b277551addc7e2ca9f44b1036a34e7f30bb8a3ab62f3

Multi-tenant edition

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

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

SHA-256: 1fc4ac435cbfc1baa8d34a644b0a0720ffc36ba87aca47ed23f3e74151a76008

Connect2id server 13.2 WAR package: c2id-mt.war

GPG signature: c2id-mt.war.asc

SHA-256: 616c1dd0d92bd44d834d334f4fc6bad692c73cd7502ee0b90e5ffab5d9e776d8

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

13.2 (2023-01-12)

Summary

  • Upgrades OpenID Connect Federation 1.0 draft 25 support to publish a signed JWK set at the URL advertised in the signed_jwks_uri OpenID provider metadata found in the entity configuration.

  • Fixes two bugs affecting deployments of Connect2id server v13.0 and v13.1 with an SQL database. Updating is strongly recommended (see issue server/816 for details).

Web API

  • /.well-known/openid-configuration

    • signed_jwks_uri -- New optional metadata field specifying an endpoint where the OpenID provider JWK set is published as a signed JWT. Available when OpenID Connect Federation 1.0 is enabled, else omitted.

  • /jwks.jwt -- New endpoint publishing the OpenID provider JWK set as a signed JWT when OpenID Connect Federation 1.0 is enabled. The JWT is signed with the RS256 algorithm using the first RSA key in the configured Connect2id server federation entity JWK set. The JWT typ (type) header is set to jwk-set+jwt. The JWT contains the iss (issuer), sub (subject), iat (issued-at time) and keys (JWK set keys) claims, as specified in OpenID Connect Federation 1.0, section 4.1.

Resolved issues

  • Fixes a bug introduced in Connect2id server 13.0, multi-tenant edition, affecting deployments with MySQL, PostgreSQL and MS SQL Server that may cause false HTTP 404 (invalid authorisation session ID) responses from the authorisation session web API. Connect2id server 13.0 and 13.1 multi-tenant deployments are strongly recommended updating (issue server/816).

  • Fixes a bug introduced in Connect2id server 13.0 affecting deployments with MySQL, PostgreSQL and MS SQL Server that causes incorrect PAR URI rejections at the authorisation endpoint. Connect2id server 13.0 and 13.1 deployments are strongly recommended updating (issue server/818).

  • Fixes non-critical NPE when writing HTTP 404 responses at the .well-known/openid-federation endpoint when OpenID Connect Federation 1.0 is disabled (issue server/817).

  • Optimises OpenID Connect Federation 1.0 related logging (issue server/815).

  • The PARValidator SPI must be invoked with an AuthenticationRequest if the validated authorisation request has the "openid" scope value (issue server/819).

Dependency changes

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

How to design metadata assertions and policies in a OpenID Connect Federation 1.0

2023-01-05

OpenID Connect Federation 1.0 devises a new protocol for establishing trust based on JWT security infrastructure. What is the protocol good for?

  • OpenID relying parties (RPs) and providers (OPs) can find out if they can trust one another, given a common trust anchor.

  • RP and OP metadata discovery and policing

  • Automated registration of the RP as a client with the OP once mutual trust is established.

Other applications of this trust establishment are certainly possible, such as in general OAuth 2.0 and in the SIOPv2 / Wallet space.

This article is a guide for federation operators how to design the policies and assertions in a federation so that it works smoothly and securely for all its participants.

1. Metadata in OpenID Connect

Identity providers and relying parties in OpenID Connect describe their capabilities and configuration information in a JSON object called metadata.

An OpenID provider publishes its metadata at a well known URL (/.well-known/openid-configuration) so that application developers can configure their software with the necessary parameters, such as the OP's public keys URL and signing algorithm for validating ID tokens, and have their application registered as an RP in a standard compliant way.

Core OpenID Connect metadata

The core OpenID Connect OP and RP metadata is explained in two specifications, which should be familiar to anyone who has configured servers or client applications:

Sample minimal RP metadata, defining a redirection URI for receiving authorisation responses from an OpenID provider (other required parameters, such as the expected ID token signing algorithm id_token_signed_response_alg, will be assigned default values):

{
  "redirect_uris" : [ "https://rp.example.com/cb" ]
}

Extensions metadata

OPs and RPs that implement OAuth 2.0 and OpenID Connect extensions, such as mTLS, DPoP, or back-channel logout will include additional parameters in their metadata, necessary for the extension's discovery and usage.

Sample RP metadata including fields from extensions:

{
  "redirect_uris"                              : [ "https://rp.example.com/cb" ],
  "backchannel_logout_uri"                     : "https://rp.example.com/logout",
  "backchannel_logout_session_required"        : true,
  "tls_client_certificate_bound_access_tokens" : true
}

OpenID Connect federation specific metadata

To facilitate the operation of entities in a OpenID Connect Federation 1.0 there is a need to define further metadata, such as organization_name, signed_jwks_uri and federation_registration_endpoint:

Sample RP metadata with OpenID federation specific fields:

{
  "redirect_uris"                              : [ "https://rp.example.com/cb" ],
  "backchannel_logout_uri"                     : "https://rp.example.com/logout",
  "backchannel_logout_session_required"        : true,
  "tls_client_certificate_bound_access_tokens" : true,
  "organization_name"                          : "Happy Coding Enterprises",
  "client_registration_types"                  : [ "automatic" ]
}

2. Direct, asserted and policy metadata

Asserted

OP metadata RP metadata
organization_name
client_name
logo_uri
op_policy_uri policy_uri
op_tos_uri tos_uri
op_tos_uri tos_uri
jwks_uri, signed_jwks_uri, jwks
  • OP:
    • organization_name
    • op_policy_uri
    • op_tos_uri
    • jwks_uri, signed_jwks_uri, jwks
  • RP:
    • organization_name
    • client_name
    • logo_uri
    • client_uri
    • policy_uri
    • tos_uri
    • jwks_uri, signed_jwks_uri, jwks

Policy:

Ensure interop, establish baseline security

  • OP: *
  • RP: *

Direct:

Rules

General OpenID Connect policy guidelines:

  1. The purpose of OP and RP metadata policy is to

    • establish minimal interoperability
    • establish base line of security

  2. The base (default) policy for OP and RP metadata should be established by the TA. Intermediates may extend this as explained in section ...

  3. Ensure the policy for OP or RP metadata is consistent and does not contain entries that can potentially result in a JSON object that does not represent valid metadata.

    Example of a consistent RP metadata policy:

    {
 "token_endpoint_auth_method" : {
    "value" : "private_key_jwt"
 },
 "token_endpoint_auth_signing_alg" : {
    "default" : "RS256",
    "one_of" : [ "RS256", "RS384", "RS512" ]
 }
}

    Example of a conflicting policy for RP metadata where the required private_key_jwt authentication method at the token endpoint is not compatible with the allowed JWS algorithms:

    {
 "token_endpoint_auth_method" : {
    "value" : "private_key_jwt"
 },
 "token_endpoint_auth_signing_alg" : {
    "default" : "HS256",
    "one_of" : [ "HS256", "HS384", "HS512" ]
 }
}

  4. Ensure the OP metadata policy and RP metadata policy are compatible with one another and do not contain conflicting entries that can potentially prevent RPs from registering with OPs.

    Examples of compatible OP and RP policies, for the OP:

    {
 "id_token_signing_alg_values_supported" : {
    "subset_of" : [ "RS256", "RS384", "RS512" ]
 }
}

    For the RP:

    {
 "id_token_signed_response_alg" : {
    "default" : "RS256",
    "one_of"  : [ "RS256", "RS384", "RS512" ]
 }
}

    Examples of incompatible OP and RP policies, for the OP:

    {
 "id_token_signing_alg_values_supported" : {
    "subset_of" : [ "RS256", "RS384", "RS512" ]
 }
}

    For the RP:

    {
 "id_token_signed_response_alg" : {
    "default" : "ES256",
    "one_of"  : [ "ES256", "ES384", "ES512" ]
 }
}

  5. Ensure all policy entries for OP or RP metadata where OpenID Connect specifies a default value include an identically set default policy. This will prevent false negative policy checks when the RP metadata omits the metadata parameter.

    Example of an ID token signing algorithm policy that ensures the default RS256 value specified in OpenID Connect is applied before performing the one_of check:

    {
 "id_token_signed_response_alg" : {
    "default" : "RS256",
    "one_of"  : [ "RS256", "RS384", "RS512" ]
 }
}

// NO, burden is on the RP to fully spec its metadata

  1. In federations supporting automatic client registration make sure there is a suitable default policy set for each RP metadata parameter where OpenID Connect allows the parameter to be omitted, letting the OP to determine its default value, which may lead to a stuck client.

Metadata categories

  • Identification:
    • OP:
      • issuer
    • RP:
      • client_id (not technically metadata)
  • Endpoint URLs:
    • OP:
      • authorization_endpoint
      • token_endpoint
      • userinfo_endpoint
      • registration_endpoint
    • RP:
      • redirect_uris
      • initiate_login_uri
      • request_uris
  • JOSE:
    • JWK set:
      • OP / RP:
        • jwks_uri
      • RP:
        • jwks
    • Algorithms:
      • OP:
        • id_token_signing_alg_values_supported
        • id_token_encryption_alg_values_supported
        • id_token_encryption_enc_values_supported
        • userinfo_signing_alg_values_supported
        • userinfo_encryption_alg_values_supported
        • userinfo_encryption_enc_values_supported
        • request_object_signing_alg_values_supported
        • request_object_encryption_alg_values_supported
        • request_object_encryption_enc_values_supported
        • token_endpoint_auth_signing_alg_values_supported
      • RP:
        • id_token_signed_response_alg
        • id_token_encrypted_response_alg
        • id_token_encrypted_response_enc
        • userinfo_signed_response_alg
        • userinfo_encrypted_response_alg
        • userinfo_encrypted_response_enc
        • request_object_signing_alg
        • request_object_encryption_alg
        • request_object_encryption_enc
        • token_endpoint_auth_signing_alg
  • OAuth capabilities:
    • OP:
      • response_types_supported
      • response_modes_supported
      • grant_types_supported
      • request_parameter_supported
      • request_uri_parameter_supported
      • require_request_uri_registration
    • RP:
      • response_types
      • grant_types
  • OAuth client authentication:
    • OP:
      • token_endpoint_auth_methods_supported
    • RP:
      • token_endpoint_auth_method
  • User authentication and identity provisioning:
    • OP:
      • subject_types_supported
      • acr_values_supported
      • scopes_supported
      • claim_types_supported
      • claims_supported
      • claims_locales_supported
      • claims_parameter_supported
    • RP:
      • subject_type
      • sector_identifier_uri
      • default_max_age
      • require_auth_time
      • default_acr_values
  • UI:
    • OP:
      • display_values_supported
      • ui_locales_supported
      • op_policy_uri
      • op_tos_uri
      • service_documentation
    • RP:
      • client_name
      • logo_uri
      • client_uri
      • policy_uri
      • tos_uri
  • Admin:
    • RP:
      • contacts

Connect2id server 13.1 ships an OpenID Connect Federation 1.0 upgrade

2022-12-29

In August 2020 Connect2id 10.0 became capable of serving client applications adhering to a new trust establishment protocol called OpenID Connect Federation 1.0. A client and a server determine whether they can trust one another by relying on a common authority, called a trust anchor. Once mutual trust is established, the client can proceed with requesting ID and access tokens from the Connect2id server using standard OAuth 2.0 and OpenID Connect.

This protocol for establishing trust comes with a clever built-in mechanism that lets participating entities publish metadata particular to their role. An OpenID relying party can thus make its metadata discoverable by potential OpenID providers it may interact with in future, eliminating the need for explicit client registration with potentially costly human involvement.

This enables client applications to sign-in users by simply proceeding with an OpenID authentication request where the client_id is an https URL uniquely identifying the client and typically based in its web domain. The request is authenticated by signing it (as JWT) with a key which the Connect2id server can check for belonging to the client by following a chain of assertions reaching the trust anchor.

Example OpenID authentication request with a client_id set to an https://rp.example.com URL and a signed request object (JWT):

https://demo.c2id.com/login?
response_type=code
&client_id=https%3A%2F%rp.example.com
&scope=openid+profile+email
&request=eyJraWQiOiJLLVFLM0JTY0NWYTZXY2wzRHFDZXg3amQ0VFBMV1dhRkFXbnNiQnNU...

OpenID Connect Federation 1.0 is the only current practical standards based solution to run an identity scheme that can scale to many identity providers and client applications. Once an entity is enrolled with a trust anchor or a recognised intermediary all communication as well as metadata policing, discovery and updating can occur automatically, feed from manual human administration tasks. That's the reason Italy chose the protocol for its national eID in 2021, enabling the federation of about a dozen IdPs used by thousands of applications.

This release of the Connect2id server upgrades its support for OpenID Federation 1.0 to the latest draft 25. The spec received numerous refinements after the start of its adoption in Italy. It also became central to the GAIN initiative of the OpenID Foundation, where experts from the community have gathered to define an OpenID Connect profile for establishing trust and interoperability between relying parties and providers of verified identities, spanning various identity ecosystems around the world. The spec is expected to reach completion and become an official OpenID standard in 2023.

One significant feature of this Connect2id server release is the ability of the pushed authorisation request (PAR) endpoint to also handle requests from OpenID Connect Federation 1.0 relying parties without a prior client registration step. The client application only needs to authenticate its PAR by means of a public key that can be verified by means of the trust establishment protocol.

Example PAR with a client_id set to an https://rp.example.com URL and using mTLS authentication:

POST /par HTTP/1.1
Host: demo.c2id.com
Content-Type: application/x-www-form-urlencoded

response_type=code
&client_id=https%3A%2F%rp.example.com
&scope=openid%20profile%20email
&state=af0ifjsldkj
&redirect_uri=https%3A%2F%2Frp.example.org%2Fcb
&code_challenge_method=S256
&code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM

Enabling the Connect2id server to operate in a OpenID federation is relatively simple - all its takes is to configure a federation RSA JWK for the server and at least one URL that identifies its federation trust anchor / authority.

Example federation configuration:

op.federation.enable=true
op.federation.clientRegistrationTypes=explicit,automatic
op.federation.autoClientAuthMethods.ar=request_object
op.federation.autoClientAuthMethods.par=private_key_jwt,self_signed_tls_client_auth
op.federation.organizationName=Trusted IdP
op.federation.trustAnchors.1=https://federation.example.com
op.federation.authorityHints.1=https://federation.example.com

A client application that has been enrolled with a federation authority only needs to generate a signed JWT, called entity configuration, and place it at a well-known URL in its web domain. It will then be able to work the magic of the automatic client registration, requesting ID and access tokens from participating OpenID providers as if it was already registered. The OpenID Connect / OAuth 2.0 requests remain standard form and can use existing client code.

To help clients generate a signed federation entity configuration the OAuth 2.0 / OpenID Connect SDK has an extension, which also received an update for the latest draft 25. The extension can also perform trust chain resolution, for client applications that choose to verify that an OpenID provider belongs to the federation, or for clients that use dynamic OpenID provider configuration instead of hardwired.

Download 13.1

For the signature validation: Public GPG key

Standard Connect2id server edition

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

GPG signature: Connect2id-server.zip.asc

SHA-256: 428e3c6e4af227bf3341b1bd4ddbd01a0a1887bd7fdd33ce04a2d35715e4f62a

Connect2id server 13.1 WAR package: c2id.war

GPG signature: c2id.war.asc

SHA-256: 6dc45717cbc03e5002f88f99d9248fe8e4abd701594ca57ecfd44c06b822b202

Multi-tenant edition

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

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

SHA-256: 5174608ba2914c7a3b25cf240aad23725091b95eeb080353ab55006ca93345a9

Connect2id server 13.1 WAR package: c2id-mt.war

GPG signature: c2id-mt.war.asc

SHA-256: 1fe66e8ce925acd3d1c5d4a32b9d1d3dce347214a3edead86a448a6a965a0a91

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

13.1 (2022-12-23)

Summary

  • OpenID Connect Federation 1.0 upgrade.

    The pushed authorisation request (PAR) endpoint is now able to handle automatic registration clients authenticating with a public key using a JWT assertion (private_key_jwt) or mutual TLS (tls_client_auth or self_signed_tls_client_auth).

    The entity configuration, trust chain resolution and client registration is updated to draft 25 of the OpenID Connect Federation 1.0 specification.

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

  • The token introspection endpoint receives a new configuration to control the pruning of audience ("aud") values in responses.

Configuration

  • /WEB-INF/oidcProvider.properties

    • op.token.introspection.pruneAudience -- New optional configuration property to override the default Connect2id server filtering (since
      v7.17 (2019-10-12)) of audience ("aud") values in token introspection responses. If true causes the audience to be pruned to the client_id of the introspecting client, intended to prevent revealing information about recipients other than the intended in multi-audience tokens. If false the complete token audience will always be shown. Has no effect on tokens that don't specify an audience. The default value is true.

    • op.federation.autoClientAuthMethods.par -- New optional configuration property listing the enabled methods for authenticating OpenID Connect Federation 1.0 automatic client registration requests at the OAuth 2.0 pushed authorisation request (PAR) endpoint. Supported methods: private_key_jwt, tls_client_auth and self_signed_tls_client_auth.

    • op.federation.logoURI -- New optional configuration property specifying the logo URI of the OpenID provider as an OpenID Connect Federation 1.0 entity. Will appear in the entity configuration published at the /.well-known/openid-federation endpoint, under the metadata.federation_entity.logo_uri claim.

  • jose.federationJWKSet -> jose.federation.jwkSet -- Renames the Java system property name for setting the OpenID Connect Federation 1.0 entity JWK set. The Java system property overrides the /WEB-INF/federationJWKSet.json JWK set file content.

Web API

  • /.well-known/openid-federation

    • Updates the published entity configuration to OpenID Connect Federation 1.0 draft 25.

    • metadata.federation_entity.logo_uri -- New optional federation entity claim, configured by the op.federation.logoURI property.

  • /par

    • Supports OpenID Connect Federation 1.0 compliant automatic registration clients that use the private_key_jwt, tls_client_auth and self_signed_tls_client_auth methods (must be enabled in the op.federation.autoClientAuthMethods.par configuration property).

  • /federation/clients

    • Updates explicit client registration to OpenID Connect Federation 1.0 draft 25.

  • /token/introspect

    • Pruning of the audience ("aud") values in token introspection responses can be now be controlled by the optional op.token.introspection.pruneAudience configuration property.

Resolved issues

  • The PAR endpoint should clear client_secret_post, client_secret_jwt and private_key_jwt form parameter artifacts from the stored authorisation request (issue server/813).

Dependency changes

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

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

  • Upgrades to com.nimbusds:tenant-manager:7.4

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