Intro to OAuth - IETF 110

My presentation at the SAAG meeting at IETF 110

Transcript

1. Aaron Parecki • March 2021 aaronpk.com Intro to OAuth IETF 110
2. Specs are not good tutorials!
3. RFC6749 RFC6750 CLIENT TYPE AUTH METHOD GRANT TYPE RFC6819 RFC7009 RFC7592 RFC7662 RFC7636 RFC7591 RFC7519 RFC8252 OIDC RFC8414 STATE PARAM TLS CSRF UMA 2 FAPI RFC7515 RFC7516 RFC7517 RFC7518 TOKEN BINDING POP SECURITY BCP CIBA HTTP SIGNING MUTUAL TLS SPA BCP JARM JAR TOKEN EXCHANGE DPOP
4. The Password Anti-Pattern
5. The Password Anti-Pattern facebook.com ~2010
6. The Password Anti-Pattern • How do you revoke this app’s access? • Do you trust the app to not store your password? • Do you trust the app to access only the things it says it needs? • Do you trust the app to not do things like change your password or delete your account?
8. how can I let an app access my data without giving it my password?
9. password password password
10. Authorization Server Access Token Resource (API)
11. OAuth doesn't tell the app who logged in
12. Identification authentication Accessing APIs authorization
13. How OAuth Works
14. Goal of the Client: Get an access token Use the access token to make API requests
15. Authorization Code OAuth Flows Device Flow Client Credentials Implicit Password web mobile SPA browserless devices server-to-server CLI CLI >_ >_
16. POST /resource/1/update HTTP/1.1 Authorization: Bearer RsT5OjbzRn430zqMLgV3Ia Host: api.authorization-server.com description=Hello+World USING AN ACCESS TOKEN
17. ROLES IN OAUTH OAuth Server (Authorization Server) aka the token factory API (Resource Server) The Application (Client) The User (Resource Owner) Device (User Agent)
18. ROLES IN OAUTH OAuth Server (Authorization Server) aka the token factory API (Resource Server) The Application (Client) The User (Resource Owner) Device (User Agent) Travis-CI.org GitHub
19. ROLES IN OAUTH OAuth Server (Authorization Server) aka the token factory API (Resource Server) The Application (Client) The User (Resource Owner) Device (User Agent) iPhone App Okta Your API
20. Authorization Code + PKCE
21. Front Channel Back Channel https://accounts.google.com/?... Passing data via the browser's address bar The user, or malicious software, can modify the requests and responses Sent from client to server HTTPS request from client to server, so requests cannot be tampered with
22. Passing Data via the Back Channel
23. Passing Data via the Front Channel
24. User: I’d like to use this great app App: Please go to the authorization server to grant me access, take this hash with you User: I’d like to log in to this app, here's the hash it gave me AS: Here is a temporary code the app can use App: Here's the code, and the temporary secret, please give me a token User: Here is the temporary code, please use this to get a token AS: Let me verify the hash of that secret... ok here is an access token! App: Please let me access this user’s data with this access token! App: Hang on while I generate a temporary secret and hash it User 
 Agent App OAuth Server API ?
25. PKCE Ensures the app that receives the access token is the same one that started the exchange
26. Refresh tokens 

27. Refresh tokens 
 keep the user logged in
28. Application Refresh Token API (Resource Server) Access Token Authorization Server A ccess Token
29. Exchange the Refresh Token for an Access Token POST https://authorization-server.com/token grant_type=refresh_token& refresh_token=REFRESH_TOKEN& client_id=CLIENT_ID& client_secret=CLIENT_SECRET
30. New Access Token in the Response { "access_token": "RsT5OjbzRn430zqMLgV3Ia", "expires_in": 3600, "refresh_token": "64d049f8b21191e12522d5d96d5641af5e8" }
31. SIGN IN user authenticates access token & refresh token authorization request store refresh token in secure storage
32. SIGN IN biometrics unlock refresh token new access token & refresh token already has refresh token use refresh token to get new access token
33. Scope
34. Scope lets an application request limited access to data
37. The app requests certain scopes, and is confirmed by the user 
 and the authorization server
38. Access tokens
39. Access tokens are what the application uses to request data from the API
40. Types of Access Tokens MTQ0NjJkZmQ5OTM2NDE1ZTZjNGZmZjI3 eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOjEwMDAsI mlzcyI6Imh0dHBzOi8vYXV0aG9yaXphdGlvbi1zZXJ2ZXIuY29tIiw iY2lkIjoiaHR0cHM6Ly9leGFtcGxlLWFwcC5jb20iLCJpYXQiOjE0N zAwMDI3MDMsImV4cCI6MTUyOTE3NDg1MSwic2NvcGUiOiJyZWFkIHd yaXRlIn0.QiIrnmaC4VrbAYAsu0YPeuJ992p20fSxrXWPLw-gkFA Reference Self-Encoded (e.g. JWT)
41. Reference Tokens MTQ0NjJkZmQ5OTM2NDE1ZTZjNGZmZjI3 * user_id * expiration * permissions * ...
42. Self-Encoded Tokens eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOjEwMDAsI mlzcyI6Imh0dHBzOi8vYXV0aG9yaXphdGlvbi1zZXJ2ZXIuY29tIiw iY2lkIjoiaHR0cHM6Ly9leGFtcGxlLWFwcC5jb20iLCJpYXQiOjE0N zAwMDI3MDMsImV4cCI6MTUyOTE3NDg1MSwic2NvcGUiOiJyZWFkIHd yaXRlIn0.QiIrnmaC4VrbAYAsu0YPeuJ992p20fSxrXWPLw-gkFA { "sub": "{USER_ID}", "aud": "{CLIENT_ID}", "exp": 1524240821, "scope": "create" }
43. Access Token Validation The Fast Way The Strong Way Local Validation Remote Introspection eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZS I6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImp0aSI6ImI5ZDRhNzViLTA2MDMtNDgxYy1hM jgyLTY3YTk0NDJiNGRkNiIsImlhdCI6MTUzMjQwMDkyMiwiZXhwIjoxNTMyNDA0NTIyfQ.S jYROEt8lZpEOq1eKh3OxRmRk3xttOXZeD5yW8aW2k8 { "sub": "1234567890", "name": "John Doe", "admin": true, "jti": "b9d4a75b-0603-481c-a282-67a9442b4dd6", "iat": 1532400922, "exp": 1532404522 } POST https://authorization-server.com/introspect token=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3OD &client_id={CLIENT_ID} &client_secret={CLIENT_SECRET}
44. Rejecting Revoked Tokens 1:00 2:00 3:00 4:00 5:00 6:00 7:00 expired 0:00 Local Validation Remote Introspection User revokes application
45. Current Work
46. 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
47. 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 con fi dential clients Security BCP
48. OAuth 2.1 Authorization Code Client Credentials +PKCE Tokens in HTTP Header Tokens in POST Form Body
49. OAuth 2.1 oauth.net/2.1 tools.ietf.org/html/draft-ietf-oauth-v2-1
50. JWT Pro fi le for Access Tokens Describes a standard set of JWT claims to use in a JWT access token. This enables resource servers to be built with standard libraries to validate tokens.
51. Rich Authorization Requests (RAR) oauth.net/2/rich-authorization-requests
52. Pushed Authorization Requests (PAR) • Currently, the authorization request is sent in the front-channel • Front-channel is susceptible to inspection and modi fi cation • PAR initiates the OAuth fl ow from the back-channel oauth.net/2/pushed-authorization-requests
53. Specs Built on OAuth • OpenID Connect (openid.net) • FAPI (Financial-Grade API) • UMA (User-Managed Access) • IndieAuth (indieauth.net)
54. aaronpk.com oauth2simpli fi ed.com