Announcements
Reminder: OAuth Security Workshop 2025 – 26.-28.02.2025, Reykjavik, Iceland
Next month the annual OAuth Security Workshop will take place in Reykjavik 🇮🇸. The first program details have now been published. 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
Access to third-party accounts due to incorrect use of Google Login?
A recently published article on heise online (German) reports on a vulnerability in relation to Google Login. An IT security company has managed to acquire domains from companies that no longer exist and use these domains to access the third-party accounts (e.g. Slack or Zoom) of former employees of these companies. The companies had previously used the domains in Google Workspace and used Google Login with third-party providers. The vulnerability now lies not with Google, but with the third-party services (“relying parties”). When logging in with Google as the identity provider, OpenID Connect is used*. As part of the OpenID Connect flow, Google issues an ID token to the relying party, which contains the identity of the user. Contrary to the clear instructions in the OpenID Connect specification, which prescribe that only the claims “sub” and “iss” should be used together to identify the user, the relying parties have apparently used the “email” claim in this case. However, unlike the unique value of the “sub” claim, the “email” claim is identical for a new Google account if the same domain and username is used as from an old Google account that has since been deleted.
The vulnerability discovered once again underlines the importance of paying close attention to the specifications when implementing OAuth and OpenID Connect. If this is not done, serious vulnerabilities can arise despite the use of secure protocols. This specific case vividly highlights why only the claims “sub” and “iss” from the ID token must be used to determine the identity of a user—as Hackmanit also recommends to its customers in training and consulting.
* The heise article incorrectly speaks of “OAuth login”. However, OAuth was only developed for authorization. For login—that is, the authentication—of a user, it is necessary to use the OpenID Connect protocol, which is based on OAuth. Google Login correctly uses OpenID Connect.
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:
- A new version of the upcoming version OAuth 2.1 was published in November after a long period of time. Draft 12 makes minor changes, e.g. to the wording regarding client registration. OAuth 2.1 is intended to replace the (still) current version OAuth 2.0 from 2012. Insecure and outdated components (e.g., flows) will be removed compared to version 2.0 and established security mechanisms (such as PKCE) will be included in OAuth 2.1. In particular, the measures and regulations described in the important document “OAuth 2.0 Security Best Current Practice” are natively integrated into OAuth 2.1. To put it simply:
OAuth 2.0 + OAuth 2.0 Security Best Current Practice = OAuth 2.1
This means for existing or upcoming implementations: If the OAuth 2.0 Security Best Current Practice is implemented and complied with, the implementation is (largely) compatible with OAuth 2.1. In this case, there is therefore no need to worry about the update to 2.1. - The draft with best practices for the use of OAuth in single-page applications (“OAuth 2.0 for Browser-Based Applications”) was revised in three new versions in the last quarter. While two of these versions only updated minor details such as outdated references, draft version 20 addressed the comments of the “Document Shepherd” from the leadership of the OAuth Working Group. This brings the document another step closer to finalization. There were no fundamental changes based on this feedback; among other things, the texts on the “Backend For Frontend (BFF)” architecture were expanded to include clarifications. This is the most secure (and therefore recommended) architecture for SPAs that use OAuth. In addition, the requirement has been introduced that authorization servers must not require client authentication (e.g. using a client secret) for SPAs that are “public clients”*. The rationale behind this requirement is that with public clients, the client secret cannot be stored securely and—contrary to its name—must be assumed to be publicly known. Therefore, the use of a client secret in this case offers no added value and could even lead to a false perception of the existing security level.
- After the last Hackletter reported on the major step of the draft “OAuth 2.0 Protected Resource Metadata” on its way to becoming an RFC, the editing of the document's content has now been completed. Prior to this, feedback from the IESG (a governing body of the IETF) was incorporated in four new draft versions. Among other things, the wording was revised in various places to make it easier to understand. The last step before the document is assigned an RFC number is now an editorial revision by the IETF to improve final linguistic details. The final document defines a format for the metadata of resources whose access is protected via OAuth and helps OAuth clients or authorization servers to interact with these resources.
- In October, the document “OAuth 2.0 for First-Party Applications”, which was previously listed as an individual draft, was officially “adopted” by the OAuth Working Group. Apart from the initial version, which is identical in its content to the version of the individual draft, no new version has been published to date. As described in the last issue of the Hackletter, 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 flows such as the code flow. The code flow should generally be preferred whenever possible and 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.
- The draft on SD-JWT VC (“SD-JWT-based Verifiable Credentials”) has received three updates in the last quarter. In particular, the removal of any mention of DIDs (“Decentralized Identifiers”) in version 6 was controversially discussed and reversed in version 7. There are indications that additional (controversial) discussions will arise in the further development of this draft, as there appear to be differing views within the Working Group on the content and design of the draft.
* "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.
Questions, Outlook, and Discussions
- The draft on SD-JWT (“Selective Disclosure for JWTs”) caused a lot of discussion in the last quarter of 2024. A number of people on the OAuth mailing list responded to the second “Working Group Last Call”* with a review and expressed final comments and concerns. In three email threads (#1, #2, #3), the impact of the draft on privacy was discussed in detail. Various suggestions were made to adjust the “Privacy Considerations” section. Further discussion on this topic has also taken place on Github. The final text for this section had not yet been found by the time this Hackletter was published. In addition, after the second “WGLC”, the IETF “Area Director” responsible for OAuth made comments on the draft; according to the authors, these minor comments are to be incorporated in a new draft version to be published soon.
- The “Working Group Last Call”* was started for the draft “Token Status List”, which defines a mechanism, data structures, and processing rules for displaying the status of tokens (e.g., JWT, SD-JWT VC, or CBOR Web Tokens). Prior to the publication of this Hackletter, only a few minor points for improvement were noted in the email thread. Previously, three new draft versions had been published in the fourth quarter of 2024, in which the document was revised and expanded. Once the “WGLC” has been completed, the draft will move on to the next phase on its way to becoming an RFC. Interested parties should hurry if they want to take advantage of this last chance to review the draft. They should share their comments and feedback on the draft on the OAuth mailing list by January 17.
* “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.
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