OAuth Pushed Authorization Requests
OAuth Pushed Authorization Request
Wednesday 7A
Convener: Torsten Loddersted & Nat Sakimura
Notes-taker(s): Nat Sakimura
Tags for the session - technology discussed/ideas considered:
- OAuth, OpenID, JAR, PAR
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
Torsten explained his presentation.
https://www.slideshare.net/TorstenLodderstedt/pushed-authorization-requests
The problem statement:
- Authorization request integrity protection
- Size problem.
The solution for 1. is JWT Secured Authorization Request (JAR) and 2. Is the request_uri defined in JAR.
Pushed Authorization Request (PAR).
Q. How long should AS keep the request?
A. It is one time use as it contains state, nonce, pkce_challenge etc.
Q. When the authorization request must be checked?
A. When received because there are user_hint etc.
Q. What goes into the front channel?
A. Only request_uri
Q. What would be the migration path for OP?
A. Let’s talk.
Advantages
- Significantly improved security
- Request integrity
- Client authentication
- Robustness
- While offering a simple migration path.
Q. Please add the writing on the security risks of not doing this.
A. It is not only security but the robustness problem caused by the size.
OAuth Rich Authorization Request (RAR, Formally known as structured scope)
Torsten went over the slides.
https://www.slideshare.net/TorstenLodderstedt/rich-authorization-requests
Discussions on why new parameters and not re-using the “claims” parameter came up, and a heated debate ensued. It will probably have part 2.
