02-28, 12:00–12:30 (UTC), Kaldalón
RPs receive requests from various origins/contexts and control access using subject metadata. But Client ones (grant flow type, client authentication methods) are out of reach. We propose to improve this state, enabling new signalling capabilities.
OAuth2 is a framework. It has been enriched step by step over the years, to solve new cases. As part of its evolution, it has gained and loose grant types, win new Client authentication methods (mTLS, private JWT), as long as new high assurance protection mechanisms (PKCE, DPOP, RAR/PAR). Knowing and signalling into which context OAuth2 tokens have been issued is now mandatory to ensure the best access control possible over protected resources. This has been done for end-users with the introduction of Authentication Context Class Reference (ACR) and Authentication Methods Reference (AMR). Still, this has never been propagated to OAuth2 clients. In this discussion, we will:
- Justify the needs for extensions to JWT profiled OAuth2 tokens with real life example;
- Propose new claims and example of value to propagate those signals from the Authorization Servers to the Resource Providers;
- Propose new metadata for Authorization Servers to advertise their ability to provide those metadata.
In the response flow, UMA 2.0 demonstrated that Resource owner mut need to consent before a resource is disclosed; RAR and PAR demonstrated more details should be included inside the delegated authorization before a resource is disclosed; WIMSE might require another type of delegated authorization proof before a resource is disclosed; at the very least, scope changes would be a common use case for talking to the Authorization Server again before reattempting to request a resource. The Client cannot know those requirements beforehand as they could be related to Access Control constraints at the Resource Provider. So how can the Resource Provider can signal those required behavior to the Client?
RFC 9470 - OAuth 2.0 Step Up Authentication Challenge Protocol introduced the ability to expand HTTP code to request a more assured authentication process of the subject. Nothing was said for the content nor context of the request, even less for the authentication process of the Client and format of the delegated authorization proof. Still, we can rely on this RFC as a step stone to create an authorization staircase for the Client to meet the Resource Provider expectation if possible.
Alex has been involved in IAM Product Development for over twenty years now, 10 of which spent specifically using Graphs and Graph databases for Identity and Access Management. As a graph-certified and IAM-accredited consultant, he has implemented solutions for clients in the field in both Cloud and Hybrid environments. Over the years, Alex has been evangelizing the Graph approach for Access Management at various Graph and IAM conferences and published many papers and blogs on the topic. As an active and founding member of the IDPro organization and a member of its editorial committee, Alex helps review and publish content for the monthly IDPro publications. Alex now leads the research and development of the 3Edges startup, which created the best and easiest to use Graph platform on the market, specifically for building identity-aware graph-based applications. Alex holds an MSc in Knowledge Based Systems from the University of Edinburgh, UK, and is an avid Sci-Fi enthusiast.
Jeff is a Solutions Architect expert in IAM, Application Security, and Data Protection. Through 20 years as an IAM consultant for French, Canadian, and US enterprises of all sizes and business verticals, he delivered innovative solutions with respect to standards and governance frameworks. Since the last 4 years at AWS, he helps organizations enforce best practices and defense in depth for secure cloud adoption.