Focus On OAuth Developments: New Drafts and Exciting Discussions

From finalized drafts and controversial discussions to new concepts for AI agents: Here is an overview of the most exciting developments of the last quarter.

Single Sign-On News

White Paper Published: “Identity Management for Agentic AI”

The continuing spread of AI does not stop short of the OAuth universe. Just before the Hackletter was published, the OpenID Foundation (which developed the OpenID Connect standard) released a white paper dealing with authorization and authentication in the context of AI agents. “AI agents” are defined as AI-based systems that perform actions autonomously in order to achieve specific goals. On the one hand, the white paper describes solutions for authorization and authentication that are already available in today’s “simple” scenarios in the AI agent context. On the other hand, the white paper takes a look at problems regarding authorization and authentication of future AI agent generations and strategies for developing suitable solutions for these.

The OpenID Foundation concludes with a call to action for developers, architects, standards bodies, and enterprises to work together to accelerate the development of solutions for the rapidly evolving world of AI agents.

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:

• The draft “OAuth 2.0 for Browser-Based Applications”, which compiles best practices for using OAuth in single-page applications (SPAs), is now close to final publication. After the authors incorporated feedback from the IESG (a governing body of the IETF) into Draft #25, the draft was accepted by the IESG in July. The draft is now final in terms of content and is undergoing a finishing editorial process by the “RFC Editor” before it is published with an RFC number.
  
  
• “Selective Disclosure for JWTs (SD-JWT)”, which enables all claims within a JWT to be kept secret and only selected ones to be disclosed, has been in final editorial review since Q2. The draft “SD-JWT-based Verifiable Credentials (SD-JWT VC)”, which builds on it and uses the format for “Verifiable Credentials”, received two new draft versions, #10 and #11, in Q3. Among other things, a mechanism for verifying the key used to sign the JWT was removed. The removal of this mechanism, which was based on “Decentralized Identifiers (DIDs)”, had already been the subject of controversial discussions in earlier drafts. The decision, following renewed discussion, is now based on the fact that the definition of the DID mechanism should be defined in more detail in an extension.
  
  
• A draft that had not yet made it into Hackletter, “OAuth Identity and Authorization Chaining Across Domains”, was updated with two versions in Q3. The draft describes a mechanism for preserving and using identity and authorization information across different “trust domains.” For example, a client registered with authorization server A (trust domain A) can access a resource whose access is controlled by authorization server B (trust domain B). To accomplish this, the mechanism uses a combination of the RFCs “OAuth 2.0 Token Exchange” (RFC 8693) and “JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants” (RFC 7523). After minor modifications were made to the content in draft version #05, #06 was used to incorporate feedback from the “Working Group Last Call” (WGLC), which took place in September. The draft is now in the review process of one of the working group chairs.
  
  
• Work on the draft “Updates to Audience Values for OAuth 2.0 Authorization Servers” (working title, rfc7523bis) continued in Q3. Starting with the new draft version #02, the document focuses on the use case of JWTs for client authentication. In contrast, the new draft prohibits the use of SAML assertions for client authentication. Additionally, the definition of the value for the “aud” claim within the token has been relaxed: Previously, the draft required that the claim be the issuer’s “issuer identifier.” This would have led to a “breaking change” in various scenarios and was therefore amended. Now, the client is responsible for choosing a value for the “aud” claim that is “specific to the authorization server being used.”
  Just before this Hackletter was published, draft version #03 went public. This version strengthens the draft's focus on JWTs for client authentication.
  
  
• In August, the previously individual draft “JSON Web Token Best Current Practices”, which is intended to replace the current RFC 8725 as a (minor) update, was ‘adopted’ by the OAuth Working Group following a successful “call for adoption.” In the context of the Working Group, work on the draft will now continue to incorporate novel attacks on JWTs into the draft and to recommend new countermeasures. Since the publication of RFC 8725 in February 2020 attacks such as “encryption-signature confusion” and “JWE decompression bomb” have been discovered.
  
  
• At the end of July, a new version of the “Transaction Tokens” draft was published. In draft version #06, minor linguistic changes were made and a paragraph was added to emphasize that transaction tokens are not credentials for authentication. Subsequently, a WGLC was launched based on this version. As part of the WGLC, several people provided detailed feedback. One of the main focuses was to narrow the scope of the draft to clarify that transaction tokens should be used strictly within a single “trust domain.” The authors of the draft have begun to incorporate the feedback, but an updated draft version has not been released in Q3.
  
  
• Version #12 of the draft “Status Token Lists” was published with minor adjustments. The version was then submitted to the IESG for a final review on its way to becoming an RFC.

Questions, Outlook, and Discussions

• Although no draft update for the future OAuth 2.1 version was released this quarter, there was an interesting discussion: The authors of the draft proposed adding a field to the metadata of the authorization server and client that indicates support for OAuth 2.1. One of the goals is to ensure OAuth 2.1 compliance during client registration. Critics of the proposal argue that strict versioning is a poor solution for interoperability. Instead, metadata fields that indicate support for features required in OAuth 2.1 (e.g., PKCE) should be used. One author argues, however, that an AS should specify full compliance with OAuth 2.1 instead of picking out individual features. The outcome of the discussion is that the authors of the draft intend to submit a revised proposal in the future.
  
  
• In a further discussion on the OAuth mailing list, the individual draft “OAuth 2.0 step-up authorization challenge proto” was presented. The draft is an extension to RFC 9470 that allows a resource server to send detailed error messages to the client. These error messages tell the client why access to the resource was denied and what authorization requirements the client must meet for successful access.
  
  
• On the mailing list of the OAuth working group, there was a discussion about whether the OAuth standard should be adapted to accommodate flawed source code for processing tokens in the authorization header, as produced by “coding agents.” The source code of the coding agents discussed is too specific and does not allow for the flexibility that the HTTP standard provides for HTTP headers. RFC 9112 defines that HTTP headers are case-insensitive and may contain any number of spaces. The AI-generated sample code, on the other hand, specifies that the authorization header must always contain an uppercase “Bearer” followed by exactly one space before the token. At the end of the discussion, it was agreed that the OAuth standard should not deviate from the HTTP standard. Nevertheless, a non-normative recommendation could be added that clients should use an uppercase “Bearer” and only one space before the token.
  
  
• Furthermore, two individual drafts dealing with authorization for “AI agents” were presented and discussed:
  
  
  • The first draft (“AAuth - Agentic Authorization OAuth 2.1 Extension”) originates from the field of “agent-to-agent” communication. Members of the OAuth mailing list criticize, among other things, the approach that an “AI agent” should authenticate itself by possessing personal information about the person on whose behalf the agent is acting. This “knowledge-based authentication” is seen as an anti-pattern and similar to the “Resource Owner Password Credentials Grant” (ROPCG), which has since been prohibited by RFC 9700. Instead, a flow with “human-in-the-loop”, such as CIBA, is recommended for the authorization of an “AI agent”.
    
    
  • In the second draft (“OAuth2.0 Extension for AI Agent: Authorization on Target”), a new parameter is defined as an extension to an OAuth flow to specify which module of a client (e.g., an “AI agent”) requires authorization. A brief discussion addresses possible links to other drafts and future adjustments.

What's Next?

You can look forward to more exciting developments in the OAuth environment in the next quarter. Numerous drafts are nearing completion, and new discussions on AI and security mechanisms promise new momentum. Don't miss out on any news—the next Hackletter will summarize everything important for you.

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