PAR: Securing the OAuth and OpenID Connect Front-Channel
summary
Pushed Authorize Requests move all authorization parameters from the browser URL into a back‑channel PAR endpoint so the client authenticates before the front‑channel, the server returns a short‑lived request_uri (default 90 seconds), and the authorization server fetches parameters from its own store. This prevents redirect‑URI tampering and phishing, reduces URL leakage, and is already implemented in IdentityServer and ASP.NET integrations, but requires key management, client‑library support, and careful timeout/replay handling.
AI-written summary · about
chapters (13)
- 0:00Introduction to PAR
- 2:34OAuth code flow basics
- 5:11Front channel vulnerabilities
- 9:51Common attack vectors
- 13:30Limits of front channel
- 17:11JWT-secured requests (JAR)
- 20:17Shortcomings of JAR
- 25:50Pushed authorization requests
- 29:29PAR implementation demo
- 32:13PAR security advantages
- 35:33Dynamic redirect URIs
- 38:36Security considerations & QA
- 44:23Conclusion and wrap up
related talks
01h 00mSupercharging OAuth 2.0 Security
55mSupercharging OAuth 2.0 security
59mOpenID Connect & OAuth 2.0 – Security Best Practices
58mOAUTH, OPENID CONNECT & .NET – THE GOOD PARTS
58m“OAuth 2.1” and beyond
46mA Deep Dive into the Past, Present & Future of OAuth
01h 02mOpenID Connect & OAuth 2.0 – Security Best Practices
50mHow to develop to be compliant with OAuth 2.1 out of the gate