OSW25 - Reaching better access control through OAuth2 clients ext. and Step-Up AuthZ signalling

Talk with: Alex Babeanu

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.