Announcements

OAuth Security Workshop 2025 – 26.-28.02.2025, Reykjavik, Iceland

The next workshop has been announced for February 2025 and this time will take place in Reykjavik 🇮🇸 Interested parties can submit talks/sessions/tutorials etc. until 24.11.2024 or 12.01.2025 and thus contribute to the program. Details and all further information on the OSW 2025 can be found here.

The annual "OAuth Security Workshop" brings together experts from the industry, the working groups in which standards are written, and the academic environment. The goal is to strengthen the security of OAuth, OpenID Connect, and related protocols, share experiences from the use and development of the standards, and drive the future development of new standards.

Single Sign-On News

Update: No end in sight for third-party cookies in Chrome?

At the beginning of the year, Google began disabling third-party cookies for 1% of global Chrome users. By Q3, the percentage was to be steadily increased to 100% (see Hackletter Q1/2024). This would have caused problems for iframe-based single sign-on flows. In the last issue of the Hackletter, we reported on Google's adjusted schedule. This included remaining at 1% until the end of 2024 and only gradually increasing the percentage from 2025 until third-party cookies are completely deactivated. At the end of July, the original plan to completely disable third-party cookies in Chrome was abandoned. Google announced its new plan, stating that users should make an "informed decision" about whether to disable third-party cookies in their browser. This retreat from the "end of third-party cookies" is justified by ongoing concerns from regulators and feedback on "challenges" in the advertising industry. The new plan is also to be implemented with the inclusion of feedback and in consultation with the regulators.

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:

• Probably the greatest progress on the way to becoming an RFC was made last quarter on the draft "OAuth 2.0 Protected Resource Metadata". After the WGLC* for the draft was successfully completed in Q2, reviews by the IESG (a governing body of the IETF) followed in Q3. A start was made on incorporating this feedback; a total of five new versions of the draft were published in Q3. Among other things, the list of metadata fields defined in the draft was expanded to include fields for mTLS and DPoP support. It can be assumed that the last open issues from the IESG feedback will be resolved in Q4 and the content of the draft will then be final (apart from editorial details).
  
  
• The draft on SD-JWTs ("Selective Disclosure for JWTs") was updated with three new versions in Q3. Among other things, explanations on "recursive disclosures" and the risks in the context of "unlinkability" between issuers and verifiers of SD-JWTs were added. In addition, the examples contained in the draft have been improved with additional context. Based on the last published draft version #12, the WGLC* was launched until September 17. In the course of the WGLC, some lengthy discussions have arisen which will probably continue after the publication of this Hackletter. Among other things, the topic of unlinkability and the basic structure of SD-JWTs are being discussed again. It remains to be seen whether the discussions will lead to further (substantial) changes to the draft.
  
  
• In addition, two new versions of the related draft for SD-JWT VC ("SD-JWT-based Verifiable Credentials") have been published. These extend the draft to include the definition of metadata on the type of a VC and the corresponding representation, and improve/extend the illustrative examples.
  
  

*  "Working Group Last Call" refers to the last call for interested parties to review the draft and provide their comments and remarks. Once a "WGLC" has been completed, a draft usually moves on to the next phase on its way to becoming an RFC.

Questions, Outlook, and Discussions

• In the last issue of the Hackletter, we reported on the "Call for Adoption" for the "individual Draft"* "Proof of Issuer Key Authority (PIKA)", which ended without a clear result. A new call for adoption was launched in September. This time opinions were again mixed. While some people support the adoption by the OAuth Working Group, others criticize that the concerns from the first call for adoption were not sufficiently addressed. Furthermore, it is considered worth discussing whether TLS certificates should be reused for a further purpose, such as PIKA, whether this is not even in conflict with the policies of CAs, and whether PIKA can be implemented in practice at all. As with the first call for adoption, it is not clear how the draft will proceed and whether it will be adopted and further developed by the OAuth Working Group.
  
  
• The call for adoption for the "individual draft"* "OAuth 2.0 for First-Party Applications" also took place in September. The draft defines a new endpoint that allows a first-party client to perform an alternative OAuth flow without redirects in a browser. The aim is to achieve better usability for native and mobile applications than is the case with existing flows such as the code flow. The draft states that flows such as the code flow should generally be preferred and that the new flow should only be used if there is a "high" level of trust between the authorization server and the client—as is the case with first-party applications. In the Call for Adoption, some people have shown their support and noted that the draft provides a standardized solution for something that first-party apps already use in proprietary approaches. On the other hand, people are questioning whether the flow described is not similar to the "Resource Owner Password Credentials Grant" (ROPCG), the use of which is (for good reason) prohibited in the OAuth 2.0 Security Best Current Practice. The new flow could offer the same vulnerabilities as the ROPCG. It is also questioned how it is possible to ensure that the new flow is only used by first-party apps. As with PIKA, it is not yet clear whether the draft will be further developed in the name of the OAuth Working Group or whether it will remain an "individual draft".
  
  
• At the beginning of the quarter, a person drew attention to a security problem with the handling of the state parameter. Some clients use the value of the state parameter for an (internal) redirect after the OAuth/OpenID Connect flow has been completed. This redirect can be used by an attacker to redirect a victim from the client to a malicious website—a so-called "open redirect" vulnerability. This is not a new problem. As an example, the thread talked about two clients that use Google as an authorization server and insert the value of the state parameter into the Location header for the redirect without validation. The experts involved in the thread agreed that this is not a vulnerability on the authorization server side. The validation of the state parameter is the responsibility of the client. The client must compare the value on receipt with the expected value and must ensure that no open redirect occurs.
  Nevertheless, authorization servers can also be susceptible to open redirect vulnerabilities if the validation of the redirect URI is flawed. Such a vulnerability was recently identified by Hackmanit in "Keycloak" (CVE-2024-8883).
  
  
• A question arose about the use of "refresh token rotation". The background was whether the use of refresh token rotation depends on the grant type used (e.g, authorization code or refresh token) and the structure of the tokens (JWTs or random strings). The responses of several members of the OAuth Working Group were in agreement that the use of refresh token rotation depends neither on the grant type used nor on the structure of the tokens. It is up to the authorization server to decide whether refresh token rotation is used—globally for all clients or individually for certain clients.
  "Refresh token rotation" describes the issuing of a new refresh token together with the new access token when a client redeems a refresh token at the authorization server.
  
  
• A new "individual draft"* was briefly discussed. This draft ("OAuth Client ID Metadata Document") defines a mechanism with the help of which a client can identify itself to authorization servers—without prior (dynamic or manual) registration. This is achieved by the client providing metadata at a URL and sending this URL in the client_id parameter to the authorization server.
  
  

 * Most drafts start as “individual drafts”. This means that they are published and edited by the authors without any connection to a working group. Individual drafts can be “adopted” by a working group (“call for adoption”), then be further processed in the name of the working group, and later be published as an RFC.

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