Single Sign-On News

Third-Party Cookies in Chrome Remain Unchanged 🍪🍪🍪

Over the past year, the plans to end support for third-party cookies in Google Chrome have repeatedly come to our attention. From the timeline to completely remove third-party cookies by the end of 2024 (Q1/2024), to the adjustment of the timeline (Q2/2024), to the later abandonment of the original plan (Q3/2024).

At the beginning of April 2025, Google has announced that the current implementation in Google Chrome will remain in place, “offering users third-party cookie choice in Chrome”. Once again, this shift away from the planned strategy is based on feedback from the “ecosystem” (publishers, developers, regulators, and the ads industry).

For single sign-on flows in the browser, which would have been directly affected by the removal of third-party cookies, Google's decision means there is no longer a problem. For Google Chrome users who do not manually disable support for third-party cookies, however, Google's decision means that there will be no planned strengthening of their privacy when using Google Chrome.

Critical Vulnerability in node.js SAML Library “samlify”

A vulnerability in the SAML library “samlify” published by Endor Labs in May allows attackers to authenticate themselves in applications as arbitrary users (e.g., admins). The vulnerability is based on a simple flaw in the processing of signed SAML assertions. This flaw enables so-called “XML Signature Wrapping” (XSW) attacks*. Github classifies the vulnerability as critical with the highest possible CVSS score of 9.9. Applications that use samlify in versions < 2.10.0 should therefore be updated to the latest version of the library as soon as possible.

* An explanation of XSW attacks can be found in our blog post. In this post, we report on a similar vulnerability that we discovered a few years ago as part of a penetration test in a SAML library for PHP.

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:

• In the last issue of the Hackletter, the SSO news section contained a report about a vulnerability related to JWTs used for client authentication (RFC 7523 and OIDC). This vulnerability means that an attacker may be able to abuse a JWT that has been signed by a client. This could allow attackers to authenticate themselves in the name of the client. The vulnerability results from the different definition of the “audience” claim (aud) in various OAuth specifications that use JWTs. This claim specifies who the intended recipient of the token is. Only clients that support multiple authorization servers / identity providers are affected by this vulnerability.
  The draft with the (working) title “Updates to Audience Values for OAuth 2.0 Authorization Servers” (rfc7523bis) is intended to update RFC 7523 and other affected RFCs with countermeasures. The document specifies that the “audience” claim should only contain the “issuer identifier” of the authorization server. This identifier can be found in the IdP's metadata, for example, and is written to the issuer claim (iss) for tokens issued by the IdP. A new version of the draft rfc7523bis was published in Q2. Prior to this, there were discussions on the mailing list and at IETF conferences about how the structure of the document can be as clear and comprehensible as possible and how the document can be completed as timely as possible. This should ensure that the identified vulnerabilities can be quickly and effectively fixed by developers of libraries and frameworks.
  
  
• RFC 9728 (“OAuth 2.0 Protected Resource Metadata”) was finally published in mid-April. The RFC defines a format for describing resource metadata. With the help of this metadata, OAuth clients or authorization servers can find out how to interact with the resources.
  
  
• In Q2, four new versions of the draft “Selective Disclosure for JWTs (SD-JWT)” were published, correcting minor errors from a final feedback and implementing editorial improvements. Draft #22 was accepted by the IESG (a governing body of the IETF) at the end of May. This means that the content of the draft is now final and only one more editorial revision by the “RFC Editor” remains before the draft is published as an RFC. Publication could take place in Q3. SD-JWTs allow selected claims of a JWT to be disclosed while keeping all other claims secret. This can be used in the context of “verifiable credentials”, for example, to only disclose that a person is of legal age without revealing any other personal information (date of birth, name, ...). A draft for verifiable credentials based on SD-JWTs is already under development.
  
  
• At the end of Q1, the OAuth working group called for final comments on the draft “Status Token Lists”. Some people responded to this call and criticized open issues and ambiguities in the document. After some of the criticized issues were resolved, an agreement was reached that the document is considered “finished” by the working group. This was followed by a shepherd's review by one of the working group chairs, in the course of which some minor improvements were proposed and implemented in draft Version 11. In the next step, the IESG will soon look at the draft and also provide feedback and suggestions for improvement.
• A new draft version of the upcoming version OAuth 2.1 was published in Q2. However, this only contains minimal changes and mainly serves to ensure that the draft is once again displayed as “Active” in the IETF Datatracker. Previously, the “Expired” status there had led to the question of whether version 2.1 of OAuth was still being worked on. Work continues in the background, while the authors have recently made significant progress on other documents (e.g., “OAuth 2.0 for Browser-Based Applications”, see Hackletter Q1/2025).
  
  
•  There has also been published a new draft version of "Cross-Device Flows: Security Best Current Practice", introducing minor changes. The draft describes threats and countermeasures for so-called “cross-device flows”. This refers to flows in which several devices are involved. A typical example is logging in on a smart TV with the help of a smartphone, on which the actual authorization or authentication of the user takes place. The people in the working group have considered the content of the draft to be “finished” since Q2/2024. Since then, the draft has been waiting for the next step on its path to publication as an RFC: the reviews and the implementation of feedback from these reviews from other bodies within the IETF.

Questions, Outlook, and Discussions

• After we were able to announce the final publication of RFC 9700 - “Best Current Practice for OAuth 2.0 Security” - in the last issue of the Hackletter, there is now already a first draft that is intended to be an update for or an extension to RFC 9700. So far, however, this draft (“Updates to OAuth 2.0 Security Best Current Practice”) has only been published as an “individual draft”, i.e. it has been published by individuals and is not officially being edited by the OAuth working group. If the working group considers the content to be useful, it can “adopt” the draft and publish it in the OAuth context later. It was expected within the working group from the start that a new document with new security recommendations would be initiated after publication of RFC 9700 - as soon as new attacks are discovered that require new recommendations and countermeasures.
  
  The recently published individual draft is at a very early stage. The current version addresses:
  • “Audience Injection Attacks”
    This refers to the attacks that are to be prevented with rfc7523bis, see draft updates above.
  • New Variants and Use Cases for “Mix-up Attacks”
    You can find an example of a previously discovered variant and the appropriate countermeasure in our blog post on mix-up attacks.
    
    
• At the beginning of June, an individual draft entitled “Deferred Key Binding for OAuth” was presented for discussion. The draft is intended to define a procedure that allows a token to be bound to a key that the requesting party does not possess itself. Concerns have been expressed that this procedure could undermine the security assumptions made in proof-of-possession (PoP) procedures. On the other hand, several people confirmed that similar procedures are already used in practice and that there is therefore a need to standardize a solution.
  
  
• At the end of June, the same author presented and discussed another individual draft on the OAuth mailing list. The draft for “Pushed Client Registration” provides for previously unregistered clients to send their metadata for client registration as part of a “Pushed Authorization Request” (PAR, RFC 9126). This is intended to circumvent restrictions regarding the use of a fixed client ID for short-lived and highly dynamic clients. The differences to the already existing Dynamic Client Registration (RFC 7591) are discussed. In addition, concerns are expressed regarding the “trust model” and the management of the tokens of such short-lived clients.
  
  
• On the mailing list of the “AB/Connect” Working Group of the OpenID Foundation (in which OpenID Connect was standardized, among other things), the question was raised how a party can communicate if a field that usually contains a validity period or timestamp (e.g., expiry time of a refresh token) should contain “infinite” or an unlimited validity. Various options have been discussed; so far with no clear conclusion. A few days ago, the same author presented an individual draft (“OAuth 2.0 Refresh Token and Consent Expiration”) that adds a field for the validity period of the issued refresh token to the token response of the authorization server. The question for this information has already been repeatedly raised and discussed in the context of OAuth 2.1.

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