Connect2id server 19.5

3 December 2025

The DPoP (RFC 9449) OAuth 2.0 security extension enables a client to bind an access token to a private key it controls, ensuring that only the holder of that key can legitimately use the token.

This Connect2id server release extends that protection to two additional security credentials encountered in OAuth and OpenID Connect:

DPoP binding of authorisation codes, and
DPoP binding of device secrets in OpenID Connect native SSO.

DPoP binding of authorisation codes

Binding the authorisation code to the DPoP proof used with PAR gives the server a cryptographically verifiable way to authenticate the origin of the authorisation request.

For public clients, which cannot rely on client authentication at the PAR endpoint, this provides a crucial layer of protection in addition to PKCE (RFC 7636). PKCE ensures that only the legitimate client instance can redeem the authorisation code, but it does not authenticate who actually initiated the authorisation request. By binding the code to the PAR DPoP proof, the server can confirm that the request genuinely originated from the client instance holding the private DPoP key.

This prevents code injection and request-hijacking attacks that PKCE alone cannot stop, and ensures that the authorisation code cannot be replayed or consumed by another party at the token endpoint. Together, PAR + DPoP proof + PKCE significantly strengthen the integrity of the OAuth flow for public clients without adding friction to the client.

The use of DPoP proofs at the PAR endpoint is specified in section 10.1 of RFC 9449.

Example pushed authorisation request for a public client with a DPoP proof header and PKCE security:

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

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

DPoP binding of device secrets for native SSO

The OpenID Connect extension for enabling seamless SSO in a group of native apps relies on a shared secret, the device_secret, a kind of session cookie persisted on the user’s device. In the original native SSO specification the device_secret is a simple bearer credential. This Connect2id server release introduces the industry’s first implementation of DPoP binding for the device_secret, upgrading it to a true proof-of-possession credential.

A group of native clients with SSO between them will automatically receive a DPoP-bound device_secret if they submit a DPoP proof at the token endpoint to obtain DPoP access tokens (and refresh tokens, if such are allowed). Note that in this case the private DPoP key must be shared between the clients in the group, and its lifecycle must be managed collectively by them. Other than that, no additional changes are required.

Example back-channel SSO request by a client app using a DPoP proof header to demonstrate possession of the private key for the device_secret and to bind the issued access token (and refresh token, if included in the response).

POST /token HTTP/1.1
Host: c2id.com
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2IiwiandrIjp7Imt0eSI6IkVDIiwieC...
Content-Type: application/x-www-form-urlencoded

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
&subject_token=eyJraWQiOiIxZTlnZGs3IiwiYWxnIjoiUl...
&subject_token_type=urn%3Aopenid%3Aparams%3Atoken-type%3Aid-token
&actor_token=WYqFXK7Q4HFnJv0hiT3Fgw.-oVkvSXgalUuMQDfEsh1lw
&actor_token_type=urn%3Aopenid%3Aparams%3Atoken-type%3Adevice-secret
&scope=openid%20email%20profile

To find out more about OpenID Connect native SSO check out our introductory guide.

Dependency updates

This release updates the JDBC driver for Microsoft SQL Server databases, which patches a recently discovered CVE-2025-59250 vulnerability. Connect2id server deployments that use an SQL Server database are strongly recommended to update to close any potential risks due to the vulnerability.

The Jersey client CVE-2025-12383 vulnerability discovered in November does not affect the Connect2id server because it’s a transitive dependency for a test-scoped dependency that is not included in the production package and not used in production. Nevertheless, all Jersey related dependencies were updated to the latest 3.1.10.

More information about the new release can be found in the notes below.

Download 19.5

For the signature validation: Public GPG key

Standard Connect2id server edition

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

GPG signature: Connect2id-server.zip.asc

SHA-256: 62e649b8505274bb423c282e865c83019057b8af34391099a2929782772151a6

Connect2id server 19.5 WAR package: c2id.war

GPG signature: c2id.war.asc

SHA-256: b474bebe5e9cf1316ebc39e478fab94c54f94e56fef16849e242ff40bca311ec

Multi-tenant edition

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

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

SHA-256: 7b315c14602366dd5ea422a41198d6b9737bb01c6b394f81a3e423f06012b40f

Connect2id server 19.5 WAR package: c2id-mt.war

GPG signature: c2id-mt.war.asc

SHA-256: 410b8647c0e43cf4b1ec6622e60743d7fc429c4c5fa0b757931f269561019436

Questions?

For 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

19.5 (2025-12-02)

Summary

Supports DPoP binding of authorisation codes via the dpop_jkt (DPoP JSON
Web Key thumbprint) authorisation request parameter (RFC 9449, section 10). This enables end-to-end binding of the authorisation to the private client DPoP key used to bind access tokens (and any refresh token, for a public client). Note that the DPoP binding of authorisation codes is optional and does not replace PKCE as a security measure, unless the client generates a unique private DPoP key for each authorisation request.
Supports DPoP binding of device secrets in OpenID Connect Native SSO for Mobile Apps 1.0. This feature is optional and specific to the Connect2id server. It enables a group of clients that allow SSO between them to bind the device_secret to the private DPoP key used to bind access tokens (and any refresh tokens, for a group of public clients). The private DPoP key must be shared between all clients in the native client group.

Web API

/par
- Supports the DPoP HTTP request header to enable clients to pass a DPoP proof, which is then converted to a dpop_jkt (DPoP JSON Web Key thumbprint) parameter appended to the pushed authorisation request (RFC 9449, section 10.1). If the pushed authorisation request includes an identical dpop_jkt parameter this is ignored. If the pushed authorisation request includes a dpop_jkt parameter with a different valued the request is rejected with an invalid_dpop_proof error.
/authz-sessions/rest/v3/
- Supports the optional dpop_jkt (DPoP JSON Web Key thumbprint) authorisation request parameter (RFC 9449, section 10).
/token
- Supports DPoP binding (RFC 9449) of the device_secret in OpenID Connect Native SSO for Mobile Apps 1.0.
  
  A client that makes a token request with an authorisation code grant in the Native SSO flow and includes a DPoP proof will receive a DPoP-bound device_secret in the response, in addition to a DPoP-bound access token.
  
  A client that makes a token request with a token exchange grant for Native SSO must include a valid DPoP proof if the device_secret is DPoP-bound.

Resolved issues

Do not include DPoP proof claim values and related details in the error_description of invalid_dpop_proof errors returned at the token and pushed authorisation request (PAR) endpoints, and in the error_description of invalid_token errors returned at the UserInfo endpoints (issue server / 1133).
Sanitise and abbreviate the OAuth 2.0 authorisation code in AS0202 log INFO messages (issue authz-store / 247).
Don’t log the received OAuth 2.0 redirect_uri in AS0205 log INFO messages (issue authz-store / 245).
Log the following conditions at the token endpoint for an authorisation code grant with OpenID Connect Native SSO: Invalid / expired device_secret; supplied device_secret not for native client group (NCG) session; subject of supplied device_secret doesn’t match authenticated subject (issue server / 1136).

Dependency changes

Updates to com.nimbusds:oauth2-oidc-sdk:11.30.1
Updates to com.nimbusds:c2id-server-key-store:1.7.8
Upgrades to com.nimbusds:oauth2-authz-store:28.10.1
Updates to com.nimbusds:oidc-session-store:22.1.6
Updates to com.nimbusds:nimbus-jose-jwt:10.6
Updates to com.nimbusds:c2id-server-jwkset:2.0.6
Updates to com.nimbusds:common:3.7.3
Updates to commons-codec:commons-codec:1.18.0
Updates to Jersey JAX-RS 3.1.10
Updates to com.microsoft.sqlserver:mssql-jdbc:12.10.2.jre11
Updates to com.nimbusds:tenant-registry:9.0.10