5. @aaronpkJune 2020
The State of OAuth 2.0
RFC6749 OAuth Core
Authorization Code
Implicit
Password
Client Credentials
GrantTypes
RFC6750 Bearer Tokens
TokenUsage
Tokens in HTTP Header
Tokens in POST Form Body
Tokens in GET Query String
7. @aaronpkJune 2020
OAuth Server OAuth Client
Passing Data via the Front Channel
Did they catch
it? Did someone else
steal it?
Is this really
from the real
OAuth server?
8. @aaronpkJune 2020
The State of OAuth 2.0
RFC6749 OAuth Core
Authorization Code
Implicit
Password
Client Credentials
RFC6750 Bearer Tokens
RFC7636
+PKCE
Tokens in HTTP Header
Tokens in POST Form Body
Tokens in GET Query String
9. @aaronpkJune 2020
The State of OAuth 2.0
RFC6749 OAuth Core
Authorization Code
Implicit
Password
Client Credentials
RFC6750 Bearer Tokens
RFC7636
+PKCE
RFC8252
PKCE for mobile
Tokens in HTTP Header
Tokens in POST Form Body
Tokens in GET Query String
10. @aaronpkJune 2020
The State of OAuth 2.0
RFC6749 OAuth Core
Authorization Code
Implicit
Password
Client Credentials
RFC6750 Bearer Tokens
RFC7636
+PKCE
RFC8252
PKCE for mobile
Browser App BCP
PKCE for SPAs
Tokens in HTTP Header
Tokens in POST Form Body
Tokens in GET Query String
14. @aaronpkJune 2020
The State of OAuth 2.0
RFC6749 OAuth Core
Authorization Code
Implicit
Password
Client Credentials
RFC6750 Bearer Tokens
RFC7636
+PKCE
RFC8252
PKCE for mobile
Browser App BCP
PKCE for SPAs
Tokens in HTTP Header
Tokens in POST Form Body
Tokens in GET Query String
15. @aaronpkJune 2020
The State of OAuth 2.0
RFC6749 OAuth Core
Authorization Code
Implicit
Password
Client Credentials
RFC6750 Bearer Tokens
RFC7636
+PKCE
RFC8252
PKCE for mobile
Browser App BCP
PKCE for SPAs
Tokens in HTTP Header
Tokens in POST Form Body
Tokens in GET Query String
18. @aaronpkJune 2020
The State of OAuth 2.0
RFC6749 OAuth Core
Authorization Code
Implicit
Password
Client Credentials
RFC6750 Bearer Tokens
Tokens in HTTP Header
Tokens in POST Form Body
Tokens in GET Query String
RFC7636
+PKCE
RFC8252
PKCE for mobile
Browser App BCP
PKCE for SPAs
PKCE for
confidential
clients
Security BCP
21. @aaronpkJune 2020
Password
• Exposes the username and password to the application
• Even for first-party / trusted clients, this increases the attack surface
• Trains users that it's okay to enter their password in more than one place
• Difficult or impossible to extend to support multifactor or passwordless
authentication (WebCrypto, WebAuthn)
22. @aaronpkJune 2020
OAuth 2.0 Security BCP
• All OAuth clients MUST use PKCE with the authorization code flow
• Password grant MUST NOT be used
• Use exact string matching for redirect URIs
• No access tokens in query strings
• Refresh tokens for public clients must be
sender-constrained or one-time use
oauth.net/2/oauth-best-practice
28. @aaronpkJune 2020
Rich Authorization Requests (RAR)
• OAuth "scope" is limited to fixed lists of scopes
• Need a way to authorize fine-grained transactions or resources
• and present that to the user in the authorization interface
oauth.net/2/rich-authorization-requests
31. @aaronpkJune 2020
Pushed Authorization Requests (PAR)
• Currently, the authorization request is sent in the front-channel
• Front-channel is susceptible to inspection and modification
• PAR initiates the OAuth flow from the back-channel
oauth.net/2/pushed-authorization-requests
32. @aaronpkJune 2020
Pushed Authorization Requests (PAR)
GET /authorize?response_type=code
&client_id=s6BhdRkqt3&state=af0ifjsldkj
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb HTTP/1.1
Host: as.example.com
POST /as/par HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3
response_type=code
&client_id=s6BhdRkqt3&state=af0ifjsldkj
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
Instead of:
Push the request to the AS:
oauth.net/2/pushed-authorization-requests
33. @aaronpkJune 2020
Pushed Authorization Requests (PAR)
{
"request_uri": "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2",
"expires_in": 90
}
GET /authorize?request_uri=
urn%3Aexample%3Abwc4JK-ESC0w8acc191e-Y1LTC2 HTTP/1.1
AS responds with a URL:
User visits that URL, authorization request details are hidden!
oauth.net/2/pushed-authorization-requests
34. @aaronpkJune 2020
JWT Authorization Requests (JAR)
• Create a signed JWT with the authorization request details
• Prevents front-channel tampering with the request, similar to PAR
• Authenticates the request so the AS knows the client really did initiate it
tools.ietf.org/html/draft-ietf-oauth-jwsreq
36. @aaronpkJune 2020
JWT Authorization Requests (JAR)
https://server.example.com/authorize?request=eyJhbGciOiJS...
Either passed by value in the URL:
https://server.example.com/authorize?request_uri=https://example.org/r...
...by reference in the URL:
POST https://server.example.com/authorize
request=eyJhbGciOiJS...
...or pushed using PAR:
tools.ietf.org/html/draft-ietf-oauth-jwsreq
38. @aaronpkJune 2020
The State of OAuth 2.0
RFC6749 OAuth Core
Authorization Code
Implicit
Password
Client Credentials
RFC6750 Bearer Tokens
Tokens in HTTP Header
Tokens in POST Form Body
Tokens in GET Query String
RFC7636
+PKCE
RFC8252
PKCE for mobile
Browser App BCP
PKCE for SPAs
PKCE for
confidential
clients
Security BCP
41. @aaronpkJune 2020
OAuth 2.1
Consolidate the OAuth 2.0 specs,
adding best practices,
removing deprecated features
Capture current best practices in OAuth
2.0 under a single name
Add references to extensions that didn't
exist when OAuth 2.0 was published
42. @aaronpkJune 2020
OAuth 2.1
No new behavior defined by OAuth 2.1
Non-Goals:
Don't include anything experimental,
in progress or not widely implemented
43. @aaronpkJune 2020
OAuth 2.1
RFC6749 - OAuth 2.0 Core
RFC6750 - Bearer Token Usage
RFC7636 - PKCE
Native App & Browser-Based App BCPs
Security BCP
• MUST support PKCE for all OAuth clients
• No password grant
• No implicit flow
• Exact string matching for redirect URIs
• No access tokens in query strings
• Refresh tokens must be sender-constrained or one-time use
47. @aaronpkJune 2020
OAuth 3
• In development under a new IETF working group (GNAP)
• Re-thinking OAuth from the ground up
• Not backwards compatible
• Consolidate all the various use cases in OAuth into a new framework