The OAuth Security Workshop 25 (OSW) took place in Reykjavik, Iceland this year, in the last week of February. Currently in its 10th year, the workshop was initially created by two different research groups from the Universities of Ruhr-Bochum and Trier who independently discovered attacks on OAuth and OpenID Connect around the same time. These researchers first met in Darmstadt in 2015 with members of the OAuth working group to discuss the issues they surfaced and find mitigation strategies. The participants also decided that given the need for a better exchange of information and knowledge, a regular meeting or event was necessary. The OAuth Security Workshop was born, with the goal of ensuring that research and standardization efforts go in sync. Since then, the OSW has been run and organized independently by Dr Daniel Fett, Guido Schmitz, Steinar Noem without corporate backing or funding. Thankfully, individual workshops have corporate sponsors, but we still have to thank Daniel, Guido, and Steinar for their volunteer efforts in keeping this community alive and thriving for the past decade! As participants like to point out themselves, OSW is a meeting place for a couple hundred geeks, but those are the geeks who actually drive those standards for Identity that the current World Wide Web is built upon!
OSW Sessions of Interest
OSW is itself part conference, part unconference. The mornings are dedicated to proper talks, keynotes, and sessions for different horizons – students, researchers, security architects, seasoned RFC writers, thought leaders, startup founders, and even Digital Identity Advancement Foundation “Vittorio Bertocci Award” grantees. The afternoons are open for unconference-style open sessions, the contents of which are decided each day by popular vote. Several tracks were thus discussed, these being the latest and greatest work currently in progress or published in the OAuth universe at large.
Verifiable Credentials
A set of sessions was dedicated to the various groups working on Verifiable Credentials and related specs (OID4VC, etc.). Kristina Yasuda and her peers showed that a lot of effort has been going into standardizing the formats for representing credentials, for building trust frameworks, and ensuring that these digital credentials can be read, presented and understood, and most importantly, trusted. A huge driver here is still the pan-European eIDAS initiative, whose goal is to provide all European citizens with Digital Credentials.
WIMSE-cal Workloads
On another tack, a lot of work has been going into securing Workloads, with the advent of the new Transaction Tokens and WIMSE specifications, as well as the new implementations of the not-so-new SPIFFE framework. As defined in the Transactions Token spec, a Workload is “An independent computational unit that can autonomously receive and process invocations, and can generate invocations of other workloads. Examples of workloads include containerized microservices, monolithic services and infrastructure services such as managed databases”. This also applies to our friends the AI Agents. Pieter Kasselman highlighted that workloads have two main problems: providing them with a provable unique identity that can enable them to authenticate with each other (support of which can be provided through SPIFFE, but also through a new concept of a Workload Identity Token or WIT), and ensuring that the same context is shared across all the workloads participating in the same transaction (achieved through Transaction Tokens). Access to any resource by any of these Workloads can then be properly authorized within the context of the operation at hand.
The Next Member of the OAuth Family
This topic led to some good follow-up discussions after Justin Richer presented the RFC on HTTP message signature, an alternative to DPoP, one of the legitimate children of OSW. What would happen if the workload couldn’t access the Authorization Server or the client key material? By the end of the conference a new proposal was submitted to IETF. Discussions in Bangkok promise to be epic.
FAPI
On the development/engineering security side, the FAPI 2.0 specification was also released recently. It included various updates to the security posture required from its various participants. As for gauging the security of Web Applications, the Open Worldwide Application Security Project (OWASP) just released its version 5.0 of its Application Security Verification Standard (ASVS). Elar Lang presented the ASVS project, whose primary goal is to provide an open application security standard for web apps and web services of all types. The standard provides a set of controls that can be used to assess or test the security of any system. Implementers can thus choose which controls to focus on to secure their applications.
Factors and Claims
Jeff Lombardo and Alex Babeanu have introduced a new set of claims for the JWT Access Token profile within the OAuth2 standard, along with a new flow. These proposed claims aim to enhance visibility into the Client entity itself. While existing OAuth2 flows provide extensive information about the end-user making requests to access resources (through access or ID token claims), there is little standardization around identifying and assessing the client application that the end-user is authorizing. Specifically, there is no widely accepted way to determine the level of assurance associated with the client entity. For example, how was the client authenticated? Was it a simple ID and secret, mTLS, or a signed JWT assertion? These methods vary significantly in security, with cryptographic signatures offering stronger assurances. Additionally, what security extensions were applied in the OAuth flow? Was PKCE or DPoP used? These factors can impact the overall security posture of a request.
Access Control Mechanisms
As access control mechanisms evolve, these considerations are becoming increasingly important. With the rise of AI agents, Policy Decision Points (PDPs) must assess not just the end-user but also the security of the calling application itself. By incorporating these new claims, PDPs can make more informed access control decisions, ensuring stronger and more adaptable security policies.
Thus, a better integration with AuthZEN-compliant Policy Decision Points (PDP) is proposed in a couple of ways:
- OAuth Authorization Servers (AS) should make direct AuthZEN calls to compliant PDPs as part of their usual token-minting ceremonies. This will supply the PDPs with the additional client claims described above to help in decision-making. (We are thinking in particular about RAR requests, which can be complex authorization requests).
- The authors also proposed a new Step-Up Authorization Protocol as an extension to RFC 9470, Step-Up Authentication Protocol. In this new flow, a Resource Server can request an Authorization Step-Up and require a new set of client claims from the client. The client is then responsible for obtaining these claims by, for example, authenticating using a stronger method (such as mTLS or signed assertions) and ensuring certain extensions (such as DPoP) are presented.
Work on drafts for these extensions has already started.
Closing With a Bang
Finally, as Mike Jones pointed out during his session entitled “The Cambrian explosion of OAuth and OpenID Specifications”, there are rather a LOT of standards in the OAuth universe, over 100. So much so that it can be hard for newcomers or implementers to find the right path in this forest. This is nevertheless also a sign of a healthy ecosystem, where more and more problems are tackled. Like the Cambrian explosion that our planet Earth experienced some 540 million years ago, we may be witnessing an explosion in the diversity of Digital Identity topics and concerns, a good sign that we will keep busy for the foreseeable future.
Disclaimer: The views expressed in the content are solely those of the author and do not necessarily reflect the views of the IDPro organization.
Authors:
Alex Babeanu is a seasoned expert with over two decades of building innovative IAM solutions using Graphs and Open Standards, as a principal Engineer, Consultant, Product Manager and CTO. A passionate advocate for the graph-based approach to IAM, Alex has presented at leading conferences and contributed extensively through published papers and blogs. As a founding member of IDPro and part of its editorial committee, Alex plays a key role in curating content for the organization’s monthly publications. Currently, he leads the Access Management product at Indykite, a cutting-edge platform that harnesses graph data and AI to simplify complex identity challenges.
Badges: IDPro Member, IDPro Editorial Committee, IDPro BoK Reviewer, IDPro Newsletter Author, IDPro Founding Member
Jeff Lombardo is a Solutions Architect expert in IAM, Application Security, and Data Protection. Through 15 years as an IAM consultant for French, Canadian, and US enterprises of all sizes and business verticals, he has delivered innovative solutions with respect to standards and governance frameworks. Since the last 5 years at AWS, he helps organizations enforce best practices and defense in depth for secure cloud adoption.
