OAuth 2.0 JWT-secured Authorization Requests (JARs)

🔥More exclusive content: https://productioncoder.com/you-decid...
Twitter:   / _jgoebel  
Website: https://jangoebel.com
Blog: https://productioncoder.com
JWT-secured authorization requests RFC: https://datatracker.ietf.org/doc/html...

00:00 Introduction to authorization requests in OAuth
01:37 What are JWT-secured authorization requests?
02:32 Using JWEs to encrypt authorization requests
04:24 JWT-secured authorization requests using references
06:47 Conclusion

In three-legged OAuth scenarios - specifically with the OAuth authorization code grant, the redirection to the authorization server happens via the front channel (via the url bar of the browser). The issue with this is that while the data is sent encrypted to the authorization server over the network because OAuth mandates the use of https, the parameters' integrity and authenticity and confidentiality is not protected on the user agent (i.e. the browser itself).

Therefore RFC-9101 proposes to wrap the parameters that are usually sent as query parameters via the front channel inside of a JSON Web Token (JWT). Like so the parameters can be digitally signed or MACed which protects their authenticity and their integrity. The spec also offers to nest a JSON Web Signature (JWS) token inside of a JSON Web Encryption (JWE) token to achieve confidentiality in addition.

JWT-secured authorization requests can be either passed directly in the front channel as a JWT or the spec also allows an authorization request to be passed as an URI. Passing an authorization request as an URI means that the JWT is stored on some server and once the authorization server receives the authorization requests it will fetch the authorization request from the specified URL. This is supported because a lot of mobile browsers do not support very long URLs