With our "Hackletter" you will receive quarterly news and announcements on topics, standards and developments in the field of single sign-on. Subscribe to the newsletter and never miss any news about single sign-on again.

Staying up to Date—The Most Important Single Sign-on Updates From Q2 | Hackletter Q2/2024

Staying up to Date—The Most Important Single Sign-on Updates From Q2 | Hackletter Q2/2024
Hackletter Q2/2024 Banner


Single Sign-On News

Update: Postponement of the end of third-party cookies in Chrome

Contrary to what was described in the last issue of the Hackletter, Google will not completely deactivate third-party cookies in Chrome by Q3 of this year. This has already been the case for 1% of users since January 4. Instead of gradually increasing this proportion in 2024, the proportion is to remain at 1% until the end of 2024. The new schedule envisages gradually increasing the proportion in 2025 until third-party cookies are completely deactivated in Chrome, as Google announced at the end of April. According to Google, this postponement is due to feedback on ongoing challenges in implementing new solutions from the industry and developers as well as the UK Competition and Markets Authority.

For providers of single sign-on implementations, this means more time to check whether their own SSO implementation is affected. Third-party cookies are used for SSO, especially if a seamless login is implemented via an iframe or if SSO session management has been implemented.

FedCM: A new approach for single sign-on in the browser

With “Federated Credential Management” (FedCM), a new browser API is currently in early development that can already be tested in Chrome. The use of FedCM is intended to enable single sign-on flows in the browser without technologies such as third-party cookies, while protecting the privacy and security of users.

In the context of OAuth, FedCM is a very interesting opportunity to integrate a secure and data protection-friendly solution for single sign-on directly into the browser. This direct integration can reduce implementation errors to a minimum. The OAuth community is therefore keen to contribute to the development and standardization of FedCM with experience and requirements from the use of OAuth and OpenID Connect. There were several sessions on FedCM at the OAuth Security Workshop, which took place in Rome in April. In May, there was another virtual meeting of the OAuth Working Group on this topic (video, slides), followed by further discussions on the mailing list. The authors of the FedCM draft invite interested parties to provide feedback and contribute to the development of FedCM. It will be exciting to see how FedCM develops and whether the goals set can be achieved. We will keep you up to date in the Hackletter!

 

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:

  • Four new versions of what is currently probably the most important draft in the OAuth universe - the “OAuth 2.0 Security Best Current Practice[s]” - were published in the last quarter. Even if this suggests that there have been many changes, this is not the case. Feedback from reviews by the IESG (a governing body of the IETF) was gradually incorporated into the new drafts. The latest draft (#29) was subsequently accepted by the IESG and is now being finalized. Before the final publication as an RFC, there will only be minor linguistic adjustments, but no changes to the content. The best practices for the use and implementation of OAuth and OpenID Connect described in the current draft should therefore already be implemented and adhered to today. It is difficult to estimate how long the process will take until an RFC number is assigned, as this is a comprehensive document. When the time comes and which RFC number the document has received, you will find out in one of the next newsletters.

  • Some minor changes have been made to the future version 2.1 of OAuth as part of a new draft version. Among other things, the requirements for the form in which an authorization server must or can accept the client credentials for client authentication have been adapted compared to OAuth 2.0: In 2.1, an AS must accept the client credentials as POST parameters and can accept them via HTTP Basic Authentication. In the OAuth 2.0 standard, this is still the other way around: HTTP Basic Authentication must be accepted, POST parameters can be accepted.

  • Version 18 of the draft “OAuth 2.0 for Browser-Based Applications” was published on May 1st. In addition to minor linguistic changes, the order of individual sections has been changed to improve the readability of the document. In terms of content, details on the implementation and the effects on user privacy when using the “Backend For Frontend” (BFF) architecture have been added.

  • At the end of the first quarter, the “Working Group Last Call” was launched for the draft “OAuth 2.0 Protected Resource Metadata”, which defines a format for the metadata of OAuth resources. The aim was to gather final feedback from the OAuth Working Group before the document enters the next phase of the standardization process. In April, a number of suggestions for improvement were made via the mailing list and subsequently implemented in two new draft versions. Among other things, a diagram was added to make the protocol process easier to understand. A second “Working Group Last Call” was then launched in May, after which there were no further comments; the draft is therefore “finished” from the Working Group's point of view and is now awaiting reviews by other committees within the IETF.

  • The draft “Cross-Device Flows: Security Best Current Practice” was also subject to the ‘Working Group Last Call’ in the last quarter. A new draft version was then published, in which the feedback was implemented through minor adjustments (e.g. to FIDO). The draft describes threats and corresponding countermeasures for cross-device flows. This refers to flows that take place across multiple devices: A person initiates the flow on one device (e.g. smart TV) and then performs authorization or authentication on another device that they personally trust (e.g. smartphone). Examples of cross-device flows are the “OAuth 2.0 Device Authorization Grant” or the “OpenID Connect Client-Initiated Backchannel Authentication Flow”. From the Working Group's point of view, the draft is now “finished” and awaits reviews by other committees within the IETF.

 

Questions, Outlook, and Discussions

  • A “Call for Adoption” for the “individual Draft "* "Proof of Issuer Key Authority (PIKA)” was launched on the OAuth mailing list in June. PIKA is intended to make it possible to validate offline whether a public key is trustworthy. This should be an alternative to retrieving the public key from the owner via HTTPS and could be used, for example, to validate a JWT. In the discussion, various members of the OAuth Working Group showed a fundamental interest in the draft. However, many questions were also raised about the scope of the draft, the methodology described and the relationship to existing standards. By the end of the “Call for Adoption” on June 24, no clear result could be found as to whether the draft would be “adopted” by the Working Group in its current form.

  • Another “individual draft” * with the title “OAuth Profile for Open Public Clients” was presented and discussed on the mailing list. This draft originates from the environment of email providers, but is generally intended to enable interoperability between clients and servers that use protocols such as JMAP, IMAP, SMTP, POP, CalDAV or CardDAV.

  • Looking beyond the OAuth Working Group, a proposal to create an IETF “Internet Terminology Glossary” was discussed on the mailing list. This would create a central point of contact for terms defined in various documents within the IETF. This idea is currently still at an early stage and the future will show whether more will come of it.

* Most drafts begin 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”) and then further processed in the name of the Working Group and later 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