Single Sign-On News

Access to third-party accounts due to incorrect use of Google Login?

Probably the most important draft in the OAuth universe is finished and was finally published on 30.01.25 as RFC 9700. Work on the document began in November 2016 (!). Since then, the document has been continuously expanded to include countermeasures to protect against newly discovered threats. In June last year, draft 29 was then accepted as “final” by the IESG (a governing body of the IETF) and subsequently finalized editorially (see “Draft Updates” in Hackletter Q2/24).

RFC 9700 contains, as the name suggests, a series of requirements and recommendations for the secure use of OAuth 2.0. For example, the RFC strictly advises against the use of the OAuth “implicit grant”, prohibits the “resource owner password credentials grant”, and mandates the use of the PKCE extension for public clients*. Every implementation of OAuth and OpenID Connect should adhere to the defined best current practices in order to avoid vulnerabilities and enable secure operation. As explained in the last issue of the Hackletter, the best current practices from RFC 9700 will be included natively in the future version OAuth 2.1, so in simple terms the following applies:
OAuth 2.0 + RFC 9700 = OAuth 2.1
This means for existing or planned implementations: If RFC 9700 is implemented and complied with, as discussed in our SSO training courses, for example, the implementation is (largely) compatible with OAuth 2.1.

Interesting side note: Together with RFC 9700, “JSON Web Token (JWT) Response for OAuth Token Introspection” was published as RFC 9701. This RFC defines that the response of the “OAuth 2.0 Token Introspection” (RFC 7662), which contains information about the validity of an access or refresh token, is issued in the form of a signed JWT. The recipient can therefore be sure that the information in the response originates from the authorization server and has not been manipulated. Although the RFCs are not directly related in terms of their content and RFC 9701 had been editorially completed since 2021, the RFC could not be published before RFC 9700 was published. The reason for this was that RFC 9701 contains one single “normative” reference to RFC 9700. Normative references in an RFC may only refer to final published documents and not to drafts, so that the publication of RFC 9701 could only take place after (or together with) RFC 9700.

Future Changes to “private_key_jwt” Due to Possible Vulnerabilities

OpenID Connect specifies the “private_key_jwt” mechanism for client authentication as an alternative to Client ID and Client Secret. The client signs a JWT with its private key and sends this JWT to the identity provider (IdP). The IdP is informed of the client's public key as part of the client registration so that the IdP can verify the signature of the JWT. OIDC refers to RFC 7523, which defines a similar mechanism via JWTs that are sent as “client_assertion” for client authentication.

Potential vulnerabilities have now been discovered in this mechanism that could be exploited by attackers to gain unauthorized access to tokens. The details of these vulnerabilities have not yet been published in their entirety, as countermeasures are to be implemented first. This is likely to affect scenarios in which multiple IdPs are used. In order to address the vulnerabilities, a new version of RFC 7523 is to be published, which is currently only at a very early stage (rfc7523bis). The draft specifies exactly how the value of the “aud” claim contained in the JWTs should be set. This affects not only OIDC and RFC 7523, but also other standards that use this type of client authentication (e.g., PAR and JAR, as well as FAPI 1.0 and 2.0). The other affected IETF documents are also to be updated with rfc7523bis. It can be assumed that libraries and frameworks that implement “private_key_jwt” will receive updates to fix the potential vulnerabilities. In scenarios where JWTs are used today instead of client authentication via ID and secret, increased caution should be taken and, if necessary, an independent analysis of the security should be conducted.

* "Public clients" are clients that cannot securely store their client secret. Despite the name client secret, it must be assumed with these clients that the client secret is publicly known. This means that a public client cannot be securely authenticated. As a result, authorization codes and refresh tokens issued for the public client can be redeemed by anyone. Examples of public clients are native applications that are installed on the user's end device or SPAs that are running in the user's browser. Client applications that run on a backend server, by contrast, are referred to as “confidential clients” and achieve a higher level of security because they can securely store their client secret and tokens.

Draft Updates

In the past quarter, a large number of new drafts or draft versions were published in the OAuth sphere. These include the following:

• The draft “OAuth 2.0 for Browser-Based Applications”, which defines best practices for the use of OAuth in SPAs, took a further step towards the final RFC in the first quarter of 2025. After the OAuth Working Group considered the processing of the draft to be complete, it was subjected to a further review by the IESG. During this review, aspects for improvement were pointed out, the implementation of which resulted in three new draft versions. For example, a section was added that describes how the proxy functionality of the BFF must be restricted when using the “BFF architecture”*. If errors occur during implementation, this can be exploited by an attacker to steal the access token from the BFF. In addition, further explanations have been added in some places to make the draft easier to understand for a broader audience and to require less knowledge of web and browser security mechanisms. The final feedback is expected to be incorporated in the coming quarter and publication as a final RFC could also take place in the next quarter or two.
  
  
• The draft for SD-JWT (“Selective Disclosure for JWTs”) in the latest version 17 is considered complete by the OAuth Working Group and has been forwarded to the IESG for final review. Prior to this, three new versions of the draft were published in Q1, which, in addition to minor editorial/linguistic changes, extend the “Privacy Considerations” section, among others. This section in particular had previously been controversially discussed by individual members of the OAuth Working Group.
  
  
• The “Working Group Last Call” (WGLC) for the draft “Token Status List” was started at the beginning of the year. Here, the Working Group is asked to provide final feedback before a draft moves on to the next phase on its way to becoming an RFC. A number of people responded to this call. In addition, an “interim” meeting of the OAuth Working Group was later held to discuss this draft. The draft defines a mechanism for mapping the status of tokens that are secured using JOSE or COSE (e.g., JWTs). A total of four draft versions were published in order to tackle the feedback step by step. A second WGLC was then launched based on draft version 10. Interested parties should use this last chance to review the draft and share their comments and remarks on the OAuth mailing list; they have until April 7 to do so. In addition to the changes mentioned, there was also a discussion as to whether the draft should define an extension for X.509 certificates. This would allow the status lists to also be used for the revocation of X.509 certificates as well. After discussions, however, this proposal was rejected by the majority, partly because the people involved consider the OAuth Working Group to be the wrong place for the standardization of extensions for X.509 certificates.
  
  

* The BFF architecture (“Backend For Frontend”) is the most secure (and therefore recommended) architecture for SPAs that use OAuth. The frontend does not make any requests directly to the resource (e.g., an API), but has a dynamic backend server that acts as a proxy. This allows the access tokens to be stored securely on the backend server instead of in the frontend in the browser. A cookie is used for communication between the frontend and its backend. As the OAuth client in this architecture is the backend server and not the frontend of the SPA, it is a confidential client. “Classic” SPAs that operate entirely in the browser, on the other hand, are public clients and therefore achieve a lower level of security.

Questions, Outlook, and Discussions

• For the forthcoming new version of OAuth—OAuth 2.1—one person suggested some changes. However, incorporating these suggestions into OAuth 2.1 was immediately rejected. The background to this decision is that OAuth 2.1 itself should not define any new changes, but “merely” combine OAuth 2.0 with additions and improvements from other RFCs in a single standard. This serves to increase clarity and make it easier to get started with OAuth. The person was advised to discuss the proposed changes independently of OAuth 2.1 and, if necessary, to create a separate draft in which the changes are defined. If this draft were then accepted and finalized by the OAuth Working Group, the changes could potentially also be adopted in OAuth 2.1.
  
  
• One proposal discussed on the OAuth mailing list is to use “DNS handles” (e.g., @user.server.example) as user identifiers in the OAuth context, as used by Bluesky, for example. Some people countered this proposal by pointing out that similar efforts had previously been made with ID4me (penetration test of “DENIC ID”, which is based on ID4me), but these were not successful. The initiator subsequently published an individual draft on DNS handles. So far, there have been no further responses.
  
  
• Cloudflare released “OpenPubkey SSH” (OPKSSH) in March. In a blog post, they describe how OpenID Connect can be used to enable login via SSH on servers. To do this, users must authenticate themselves with their SSO provider. The provider then issues a “PK token” containing the identity and the temporary public SSH key. According to the blog post, the integration of OPKSSH only requires a download and the adjustment of two lines in the configuration file of the SSH server. An alternative solution for SSH access via OpenID Connect is the “SSHCA” developed by WAYF, for which Hackmanit recently published a security analysis.
  
  

Always well informed - subscribe to the Hackletter now!

Sign up for the Hackletter today and don't miss any exciting issues. Receive exclusive insights into the latest developments and updates on single sign-on directly to your inbox once a quarter.

>> Subscribe to the Hackletter

Our Experts Develop the Optimal Solution for You

Single Sign-On – OAuth – FAPI

Are you faced with the decision of how to best protect your IAM scenario and your customer data? Or are you already using OAuth/OpenID Connect and wondering whether your single sign-on implementation is secure?

We will be glad to advise you; contact us for a no-obligation initial consultation. Thus, we are at your side with the following services and solutions:

IT Security Consulting  |  Training  |  Penetration Tests

Don't hesitate and find your way to secure single sign-on with us. We look forward to supporting you with your projects.

Your Contact for Single Sign-On and Secure API

Karsten Meyer zu Selhausen
karsten.meyerzuselhausen@hackmanit.de