14. Pushed Authorization Requests
• Standard defined in RFC 9126.
• Provides means for confidential and integrity-protected
authorization requests.
15. HTTP 400
Standard OAuth Authorization Requests
GET /authorize?client_id=abc&scopes=read%20write
HTTP 302
Location: /cb?code=123
Is that a legitimate client?
Are the parameters OK?
Can these end up in the browser logs?
Client Authorization
Server
16. Pushed Authorization Requests
POST /authorize/par
Authorization: Basic 0JjQlNCYOtCd0JDQpdCj0Jkh
client_id=abc&scopes=read%20write
request_id: 1234
GET /authorize?request_id=1234
Client Authorization
Server
17. Pushed Authorization Requests
• The client is authenticated before the authorization request
• Authorization request parameters can’t be tampered with
• Request parameters do not traverse through unsecure transport
• URL limitations are no longer a concern
• Ability to ease on redirect URI restrictions
25. By-value vs. By-reference
Opaque tokens should always be your preferred choice:
• Data in a JWT is meant for the API, not the client
• Data in a JWT is public – danger of releasing PII or
information about your API
• Risk of damaging integrations with incompatible changes
28. The Phantom Token Flow
Client
API
Service 1
Service 2
Authorization
Server
opaque
JWT
API
Gateway
29. The Phantom Token Flow
Client API
Authorization
Server =
Cache
API
Gateway
30. The Phantom Token Flow
Benefits:
• Better security and privacy
• Performance optimization, especially when properly using
cache
31. • Safeguard against usage of stolen/lost tokens
• Protect request and response using PAR & JARM
• Prevent confidential data from leaking or being misused
Key Takeways