In the first issue of the Hackletter in 2024 you will find interesting news on these topics:
> OAuth Security Workshop 2024
> Security Best Current Practices Heading Towards the Finish Line
> Draft Updates
> and much more …
Subscribe to the Hackletter to make sure you don't miss any future issues:
>> Subscribe to the Hackletter
Announcements
OAuth Security Workshop 2024 – 10.-12.04.2024, Rome, Italy
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.
This year's workshop will take place next week in Rome 🇮🇹. All information about the program and last minute registration can be found here. You can also meet Hackmanit on site.
Single Sign-On News
OAuth 2.0 Security Best Current Practices – Heading Towards the Finish Line of Becomming an RFC
The "Security Best Current Practices" for OAuth 2.0 are headed towards the finish line of the path to the RFC last quarter. After work on the document began almost eight (!) years ago, the "Shepherd Review" and "Area Director Review" have cleared two further hurdles on the way to publication. In addition to linguistic improvements, only minor changes were made; for example, authorization servers should now try "with reasonable effort" to prevent clients from using static values as PKCE code challenges or OpenID Connect "nonce". In the final step, the authors must now incorporate feedback from reviews by the IESG (a governing body of the IETF) and make editorial corrections at the end. The IETF will then publish the document as a final RFC. When the time comes and which RFC number the document will receive can be found in one of the next newsletters.
The best practices described in the current draft (#25) for the use and implementation of OAuth and OpenID Connect should also be implemented and followed today. At this stage of the draft, no (major) changes to the content are to be expected before publication as an RFC.
The Beginning of the End of Third-Party Cookies
After Firefox and Safari, Google Chrome has also started to block third-party cookies. On January 4, Google deactivated third-party cookies for 1% of global Chrome users. Google wants to gradually increase this percentage to 100% by Q3.
Single sign-on implementations are severely affected by the general blocking of third-party cookies. As the client and identity provider are not usually hosted under the same domain, third-party cookies are used when logging in. Without third-party cookies, problems occur. Iframe-based login flows, for example, no longer work. It is therefore advisable to check whether your own SSO implementation is affected.
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:
- OAuth 2.0 for Browser-Based Apps: After a major revision of the draft was published in the last quarter of 2023, the changes in this quarter are smaller. Among other things, the latest draft version (#17) contains further recommendations on CORS, protective measures against CSRF attacks and the security of flows that use in-browser communication (e.g., postMessage API).
- OAuth 2.0 Web Message Response Mode for Popup- and Iframe-based Authorization Flows: As part of the first version of our individual draft, we discussed the differences and similarities to the older draft "OAuth 2.0 Web Message Response Mode". We at Hackmanit are trying to improve and advance our draft through further feedback. We are hoping for a uniform and secure solution for transmitting the authorization response with code and/or tokens via the postMessage API within browser windows. This is very relevant, for example, when using OAuth/OIDC in single-page applications (SPAs).
- Selective Disclosure for JWTs (SD-JWT): With unencrypted JWTs, a recipient can read all claims. If a JWT contains personal data of the owner, it is not desirable to share all claims if they are not required for the specific purpose. Using SD-JWTs, individual claims can be "hidden" in a token so that the owner can decide which claims are disclosed to the recipient. This option has no influence on the protection against manipulation by the signature of the token. Several new versions of the SD-JWT draft have been published. New versions of the "SD-JWT-based Verifiable Credentials (SD-JWT VC)" draft have also been published.
Questions, Outlook, and Discussions
- In another thread, the question of how the "scope" parameter should be handled in the context of refresh tokens was discussed. After clarifying different interpretations of the standards, the conclusion was that a refresh token can be used to issue an access token with fewer scopes than were originally approved. However, the scope of the refresh token itself is not changed, so that new access tokens with the originally approved scopes can be issued as long as the refresh token is valid. The scopes of the new refresh token do not change when using refresh token rotation either.
- A brief discussion dealt with the question of how the basis on which a JWT Access Token was issued can be written into the token itself. As a solution, reference was made to the "acr" claim. This claim is defined as a reference for the "Authentication Context Class", to which the authentication can be counted as part of the flow.
- A question on the OAuth mailing list (archive, registration) dealt with how the value of the 2x5t#S256" parameter is calculated cryptographically correctly and which coding must be used.
- There was a lively discussion on the individual draft "OAuth Status Attestations". Among other things, the definition of various terms such as "attestation" and "(digital/verifiable) proof" was discussed. It turned out that there seems to be disagreement between different committees and standards and that there are no uniform definitions.
- The WGLC* has been started for the draft "OAuth 2.0 Protected Resource Metadata", which defines a format for metadata of OAuth resources. After completion of the WGLC, the draft will move on to the next phase on its way to an RFC. Interested parties should use this last chance to review the draft and share their comments and remarks on the OAuth mailing list; they have time until April 12 to do so.
* "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