Skip to content
Connect2id
Connect2id server

Connect2id server 10.2

The 10.2 release of the Connect2id server brings two security updates and an update to the logout API.

Preventing mix-up attacks on plain OAuth 2.0 clients

The OAuth 2.0 security topics describes the mix-up attack. An OAuth 2.0 client which interacts with two or-more authorisation servers, where the client has used dynamic client registration or one of the servers has been compromised, can become susceptible to the mix-up attack.

The universal countermeasure is to let the authorisation response include the issuer identifier, as an extra iss parameter:

HTTP/1.1 302 Found
Location: https://client.example/cb?
 code=x1848ZT64p4IirMPT0R-X3141MFPTuBX-VFL_cvaplMH58
 &state=ZWVlNDBlYzA1NjdkMDNhYjg3ZjUxZjAyNGQzMTM2NzI
 &iss=https%3A%2F%2Fc2id.com

The OAuth client, when receiving an authorisation success or error response, needs to check that the returned iss parameter matches the expected issuer URL of the authorisation server when the request was started. This measure effectively enables clients to detect mix-up attacks and prevent impersonation.

Note that because OpenID relying parties (RPs) receive an ID token, which states the issuer URL of the server, and RPs are required to validate the token iss (along with other claims in the ID token), they are not susceptible to the mix-up attack.

The iss parameter is being standardised in a new spec at the OAuth WG. The spec also defines a new server metadata parameter, authorization_response_iss_parameter_supported, to let clients find out if the iss response parameter is provided and hence they can start checking for it.

{
  "issuer"                                         : "https://c2id.com",
  "jwks_uri"                                       : "https://c2id.com/jwks.json",
  ...
  "authorization_response_iss_parameter_supported" : true
}

Starting with this release the Connect2id server will include the iss in all authorisation responses.

Tightened URI scheme security

In order to allow callbacks into native clients OAuth 2.0 and OpenID Connect allow clients to be registered with redirection URIs with schemes other than the https scheme.

An article published this week by the security researcher Lauritz Holtmann discusses a class of XSS attacks which may get launched by dynamically registered clients which have set the redirect_uri scheme to javascript, data or vbscript. Firefox was one of the first browsers that started blocking top-level data URIs in 2017, but other and older browsers can still be susceptible to this attack.

To close this loophole the Connect2id server will now prohibit registration of authorisation and post-logout redirection URIs with the schemes javascript, data and vbscript.

The Connect2id server will also block registration of client metadata parameters intended to render links in the browser with URI schemes other than https and http, such as the optional client_uri (client homepage), policy_uri (client privacy policy) and tos_uri (client terms and conditions).

Connect2id server deployments which allow open / dynamic registration are advised to upgrade.

Logout web API update

The logout session web API of the Connect2id server receives an update which fixes a shortcoming in the original design of the API.

A relying party which makes a logout request has the option to specify a post_logout_redirect_uri where the browser should be sent after the logout request is processed. This post-logout redirection URI must be registered in advance, similar to the possible redirect_uris in authorisation requests.

https://c2id.com/logout?
 id_token_hint=eyJhbGciOiJSUzI1NiIsImtpZCI6IjFlOWdkazcifQ.ewogImlzcyI6...
 &post_logout_redirect_uri=https%3A%2F%2Fclient.example.com%2Flogout-page
 &state=UVaefaeroth3dah1

When the end-user is not logged in or their session has expired the original logout API of the Connect2id server will return an invalid_session error to the UI. In cases when the RP has requested a post-logout redirection the UI would not be able to trigger the post-logout redirection, leaving the end-user at the IdP logout page.

The logout API is now updated to no longer return invalid_session errors to the UI, thus allowing a post-logout redirection also in those cases when there is no active session. Note that the post-logout redirection requires an ID token hint to be included in the request, and the Connect2id server will check it to ensure the URI is registered for the RP which received it.

Download

Standard Connect2id server edition

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

SHA-256: 13197322db606ec1a030b7d2a792901fbea0f33987b2503332603440b4089d86

Connect2id server 10.2 WAR package: c2id.war

SHA-256: ed2a5c28636a6d56029529bd77bff2cdef30c0464e3c344f59d03343a5549720

Multi-tenant edition

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

SHA-256: b0c98a1094c1d3b829afa39f2375ce66ef10e37183d9e05d82c30471d94e37da

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

SHA-256: 74e338dc23c3a4f74794f8edd34c98c1855181fd8ecdbb5079ca967ba733914d

Questions?

Contact Connect2id support.

Release notes

10.2 (2020-11-13)

Summary

  • Includes the Connect2id server issuer URL as “iss” parameter in authorisation responses. Intended for OAuth 2.0 clients using more than one authorisation server to prevent a class of attacks called “mix-up” attacks. Clients interacting with a single OAuth 2.0 server and OpenID relying parties which receive an ID token (and accordingly validate the “iss” claim) are not affected. See OAuth 2.0 Authorization Server Issuer Identifier in Authorization Response (draft-meyerzuselhausen-oauth-iss-auth-resp-01) for further details.

  • Tightens the URI scheme policy for OAuth 2.0 client metadata to prevent potential attacks using malicious “javascript”, “data” and “vbscript” schemes in old and insufficiently protected web browsers. Deployments which utilise open client registration are advised to upgrade. See the article at https://security.lauritz-holtmann.de/post/sso-security-redirect-uri/ for further details.

  • Updates the logout web API to facilitate post-logout redirections in cases when the end-user session has expired.

Configuration

  • /WEB-INF/oidcProvider.properties

    • op.policy, op.tos, op.serviceDocs – If the optional policy, terms of service and service documentation links are specified by absolute URL, the scheme must be either “https” or “http”.

Web API

  • /.well-known/openid-configuration, /.well-known/oauth-authorization-server

    • Adds the “authorization_response_iss_parameter_supported” metadata parameter (the value is set to true), as specified in OAuth 2.0 Authorization Server Issuer Identifier in Authorization Response (draft-meyerzuselhausen-oauth-iss-auth-resp-01).

  • /authz-sessions/rest/v3/

    • Includes an “iss” (issuer) parameter in OAuth 2.0 authorisation success and error responses, as specified in OAuth 2.0 Authorization Server Issuer Identifier in Authorization Response (draft-meyerzuselhausen-oauth-iss-auth-resp-01). Intended for OAuth 2.0 clients using more than one authorisation server to prevent a class of attacks called “mix-up” attacks. Clients interacting with a single OAuth 2.0 server and OpenID relying parties which receive an ID token (and accordingly validate the “iss” claim) are not affected.

  • /clients

    • Registration of OAuth 2.0 clients and OpenID relying parties with “redirect_uris” or “post_logout_redirect_uris” containing the custom URI schemes “javascript”, “data” and “vbscript” is prohibited for security reasons. Native applications can continue registering redirection URIs with custom URI schemes which don’t match the prohibited.

    • Registration of OAuth 2.0 clients with “client_uri”, “policy_uri” or “tos_uri” with URI schemes other than “https” and “http” is prohibited for security reasons.

    • Registration of OpenID relying parties will no longer permit custom URI schemes for “frontchannel_logout_uri” and “backchannel_logout_uri”. The only permitted URI scheme is “https”.

  • /logout-sessions/rest/v1/

    • Updates the logout session web API to not return an “invalid_session” error when the submitted end-user session SID (typically stored in a browser cookie at the IdP domain) is invalid or expired. OpenID relying parties (RP) making a logout request with a valid “post_logout_redirect_uri” will thus be able to complete the redirection, regardless of the end-user session state at the IdP.

      Following this change “invalid_session” errors will no longer be returned by the logout session web API.

Resolved issues

  • Prohibits registration of OAuth 2.0 clients and OpenID relying parties with “redirect_uris” or “post_logout_redirect_uris” with the custom URI schemes “javascript”, “data” and “vbscript” for security reasons. Also requires browser rendered URIs derived from client and server metadata, such as “client_uri”, “policy_uri” and “tos_uri” to have an “https” or “http” URI. See https://security.lauritz-holtmann.de/post/sso-security-redirect-uri/ for more information (issue server/611).

  • Prohibits registration of OpenID relying parties with custom “frontchannel_logout_uri” and “frontchannel_logout_uri” URI schemes, thus making “https” the only allowed URI scheme (issue server/612).

  • Improves INFO logging at the logout session endpoint (issue server/610).

Dependency changes

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