Upgrade to Pro — share decks privately, control downloads, hide ads and more …

What the Heck is OAuth?

What the Heck is OAuth?

Slides from the Okta Developer Workshop Roadshow in Chicago, Dallas and San Francisco

Aaron Parecki

July 26, 2018
Tweet

More Decks by Aaron Parecki

Other Decks in Technology

Transcript

  1. © Okta and/or its affiliates. All rights reserved. Okta Confidential

    Aaron Parecki What the heck is OAuth? July 2018 Chicago / Dallas / San Francisco
  2. Before OAuth • Apps stored the user’s password • Apps

    got complete access to a user’s account • Users couldn’t revoke access except by changing their password • Compromised apps exposed the user’s password
  3. Delegated Authorization with OAuth 2.0 I trust Google, and I

    trust Yelp only enough to let it access my contacts, but it shouldn't read my email Connect with Google https://yelp.com/
  4. OAuth 2.0 Terminology • The Application: "Client" • The API:

    "Resource Server" • The User: "Resource Owner" • Authorization Server • Access Token
  5. Obtaining an Access Token Applications use an OAuth flow to

    obtain an access token • Authorization Code Flow: web apps, native apps • Device Flow: browserless or input-constrained devices • Password: not really OAuth, only for first-party apps • Refresh Token: getting a new access token when the first one expires
  6. Registering an Application • Registering identifies the application to the

    service. • Registering an application gives you a client_id • and if the application is not a "public client", then also a client_secret
  7. Public Clients Confidential Clients The application can't keep strings secret

    JavaScript apps: "view source" Native apps: decompile and extract strings Application running on a server Has the ability to keep strings secret since code is running in a trusted environment
  8. 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 server to server Code is run on a server, not on the user's computer, so requests cannot be tampered with
  9. Authorization Server (AS) Resource Server (RS) The Best App Ever

    User: I’d like to use this great app App: Please go to the authorization server to grant me access User: I’d like to log in to “The Best App Ever”, it wants to access my photos AS: Here is a temporary code the app can use App: Here is the temporary code, please give me a token User: Here is the temporary code, please use this to get a token AS: Here is an access token! App: Please let me access this user’s data with this access token!
  10. example-app.com Connect with Google Client accounts.google.com email password Authorization Server

    accounts.google.com Yes No Allow Example App to access your public profile and contacts? example-app.com/callback Loading… Direct the user to the authorization server ?response_type=code
 &redirect_uri=example-app.com/callback
 &state=00000 User signs in Authorization server redirects back to the app ?code=XYZ123&state=00000 Exchange authorization code for an access token
  11. Build the "Log in" link • response_type=code - indicates that

    your client expects to receive an authorization code • client_id=CLIENT_ID - The client ID you received when you first created the application • redirect_uri=REDIRECT_URI - Indicates the URL to return the user to after authorization is complete, such as https://example-app.com/callback • scope=photos - A space-separated string indicating which parts of the user's account you wish to access • state=1234zyx - A random string generated by your application, which you'll verify later
  12. The user is redirected back to the application with an

    authorization code https://example.com/callback?error=access_denied The user is redirected back to the application with an error code If User Denies If User Allows https://example.com/callback? code=AUTH_CODE_HERE& state=1234zyx
  13. Verify State • The application verifies the state matches the

    value it started with • This lets the application be sure it isn't trying to exchange an attacker's authorization code
  14. Exchange the Code for an Access Token • grant_type=authorization_code -

    indicates that this request contains an authorization code • code=CODE_FROM_QUERY - Include the authorization code from the query string of this request • redirect_uri=REDIRECT_URI - This must match the redirect_uri used in the original request • client_id=CLIENT_ID - The client ID you received when you first created the application • client_secret=CLIENT_SECRET - Since this request is made from server- side code, the secret is included
  15. Exchange the Code for an Access Token POST https://api.authorization-server.com/token Content-type:

    application/x-www-form-urlencoded grant_type=authorization_code& code=AUTH_CODE_HERE& redirect_uri=REDIRECT_URI& client_id=CLIENT_ID& client_secret=CLIENT_SECRET
  16. Exchange the Code for an Access Token { "access_token":"RsT5OjbzRn430zqMLgV3Ia", "expires_in":3600,

    "refresh_token":"64d049f8b21191e12522d5d96d5641af5e8" } The server replies with an access token and expiration time or if there was an error: {"error":"invalid_request"}
  17. © Okta and/or its affiliates. All rights reserved. Okta Confidential

    Implicit Flow No Client Secret JavaScript / SPA
  18. Authorization Server (AS) Resource Server (RS) The Best App Ever

    User: I’d like to use this great app App: Please go to the authorization server to grant me access User: I’d like to log in to “The Best App Ever”, it wants to access my photos AS: Here is an access token! App: Here is the temporary code, please give me a token User: Here is the temporary code, please use this to get a token AS: Here is an access token! App: Please let me access this user’s data with this access token!
  19. Build the "Log in" link • response_type=token - indicates that

    your client expects to receive an access token • client_id=CLIENT_ID - The client ID you received when you first created the application • redirect_uri=REDIRECT_URI - Indicates the URI to return the user to after authorization is complete, such as https://example-app.com/callback • scope=photos - A space-separated string indicating which parts of the user's account you wish to access • state=1234zyx - A random string generated by your application, which you'll verify later
  20. https://example.com/auth#error=access_denied The user is redirected back to the application with

    an error code If User Denies The redirect contains an access token in the URL If User Allows https://example.com/auth#token=ACCESS_TOKEN
  21. But… use the Implicit Flow sparingly! "What is the OAuth

    2 Implicit Grant Type?" on developer.okta.com https://developer.okta.com/blog/2018/05/24/what-is-the-oauth2-implicit-grant-type https://oauth.net/2/grant-types/implicit/ • If the server requires a client secret for the Authorization Code flow • If the server doesn't support CORS requests
  22. Redirect URLs for Native Apps • There is no built-in

    security for redirect URIs like when we use DNS, • since any app can claim any URL scheme.
  23. PKCE: Proof Key for Code Exchange RFC 7636: Pioneered by

    Google • Like an on-the-fly client secret
  24. PKCE: Proof Key for Code Exchange • First create a

    "code verifier", a random string 43-128 characters long. • Compute the SHA256 hash of the code verifier, call that the code challenge • Include code_challenge=XXXXXX and code_challenge_method=S256 in the initial authorization request • Send the code verifier when exchanging the authorization code for an access token
  25. Generate the Code Verifier 4A6hBupTkAtgbaQs39RSELUEqtSWTDTcRzVh1PpxD5YVKllU Generate a random string 43-128

    characters long ipSBt30y48l401NGbLjo026cqwsRQzR5KI40AuLAdZ8 The challenge is the SHA256 hash of the verifier string base64url(sha256(code_verifier)) Generate the Code Challenge
  26. Build the "Log in" link https://authorization-server.com/auth? response_type=code& client_id=CLIENT_ID& redirect_uri=REDIRECT_URI& scope=photos&

    state=1234zyx& code_challenge=XXXXXXXXXXXXX& code_challenge_method=S256 Include the code challenge (the hashed value) in the request
  27. The user is redirected back to the application with an

    authorization code example://callback?error=access_denied The user is redirected back to the application with an error code If User Denies If User Allows example://callback? code=AUTH_CODE_HERE& state=1234zyx
  28. Exchange the Code for an Access Token Verify state, then

    make a POST request: • grant_type=authorization_code - indicates that this request contains an authorization code • code=CODE_FROM_QUERY - Include the authorization code from the query string of this request • redirect_uri=REDIRECT_URI - This must match the redirect_uri used in the original request • client_id=CLIENT_ID - The client ID you received when you first created the application • code_verifier=VERIFIER_STRING - The plaintext code verifier initially created
  29. Exchange the Code for an Access Token POST https://api.authorization-server.com/token grant_type=authorization_code&

    code=AUTH_CODE_HERE& redirect_uri=REDIRECT_URI& client_id=CLIENT_ID& code_verifier=VERIFIER_STRING Note: code verifier used in place of client secret
  30. Exchange the Code for an Access Token { "access_token":"RsT5OjbzRn430zqMLgV3Ia", "expires_in":3600,

    "refresh_token":"64d049f8b2119a12522d5dd96d5641af5e8" } The server compares the code_verifier with the code_challenge that was in the request when it generated the authorization code, and responds with an access token.
  31. PKCE: Proof Key for Code Exchange • Authenticates the code

    exchange step • Does not authenticate the app itself • Safe for clients to do with authorization servers that don't support PKCE
  32. Exchange the Username and Password for a Token POST https://api.authorization-server.com/token

    grant_type=password& username=USERNAME& password=PASSWORD& client_id=CLIENT_ID& client_secret=CLIENT_SECRET The user’s credentials are sent directly! Not a good idea for third party apps!
  33. Exchange the Client ID and Secret for a Token POST

    https://api.authorization-server.com/token grant_type=client_credentials& client_id=CLIENT_ID& client_secret=CLIENT_SECRET No user context in the request, so the access token can only 
 be used to access the application’s resources
  34. © Okta and/or its affiliates. All rights reserved. Okta Confidential

    Request a Device Code { "device_code": "NGU5OWFiNjQ5YmQwNGY3YTdmZTEyNzQ3YzQ1YSA", "user_code": "BDWD-HQPK", "verification_uri": "https://example.com/device", "interval": 5, "expires_in": 1800 } The server responds with a new device code and user code, as well as the URL the user should visit to enter the code.
  35. NLBLMDPP POST https://example.okta.com/token grant_type=urn:ietf:params:oauth:grant- type:device_code &client_id=CLIENT_ID &device_code=NGU5OWFiNjQ5YmQwNGY3YTdmZTEyNzQ3YzQ1YSA While the device

    waits for the user to enter the code and authorize the application, the device polls the token endpoint. { "error": "authorization_pending" }
  36. POST https://example.okta.com/token grant_type=urn:ietf:params:oauth:grant- type:device_code &client_id=CLIENT_ID &device_code=NGU5OWFiNjQ5YmQwNGY3YTdmZTEyNzQ3YzQ1YSA While the device waits

    for the user to enter the code and authorize the application, the device polls the token endpoint. { "error": "authorization_pending" }
  37. POST https://example.okta.com/token grant_type=urn:ietf:params:oauth:grant- type:device_code &client_id=CLIENT_ID &device_code=NGU5OWFiNjQ5YmQwNGY3YTdmZTEyNzQ3YzQ1YSA While the device waits

    for the user to enter the code and authorize the application, the device polls the token endpoint. { "error": "authorization_pending" }
  38. POST https://example.okta.com/token grant_type=urn:ietf:params:oauth:grant- type:device_code &client_id=CLIENT_ID &device_code=NGU5OWFiNjQ5YmQwNGY3YTdmZTEyNzQ3YzQ1YSA While the device waits

    for the user to enter the code and authorize the application, the device polls the token endpoint. { "error": "authorization_pending" }
  39. POST https://example.okta.com/token grant_type=urn:ietf:params:oauth:grant- type:device_code &client_id=CLIENT_ID &device_code=NGU5OWFiNjQ5YmQwNGY3YTdmZTEyNzQ3YzQ1YSA While the device waits

    for the user to enter the code and authorize the application, the device polls the token endpoint. { "error": "authorization_pending" }
  40. POST https://example.okta.com/token grant_type=urn:ietf:params:oauth:grant- type:device_code &client_id=CLIENT_ID &device_code=NGU5OWFiNjQ5YmQwNGY3YTdmZTEyNzQ3YzQ1YSA While the device waits

    for the user to enter the code and authorize the application, the device polls the token endpoint. { "access_token": "RsT5OjbzRn430zqMLgV3Ia", "expires_in": 3600, "refresh_token": "b7aab35e97298a060e0ede5b43ed1f70a8" }
  41. OpenID Connect • An Identity protocol built on top of

    OAuth 2.0 • ID Token • /userinfo – for getting more information about the user • Standard set of scopes • openid • profile • email • address • phone • offline_access
  42. If User Allows Access https://example.com/ #id_token=eyJraWQiOiJiRmxZbmkzLXRhMXFSa0lFellHc2tLeFFRVUJvczZnOU9RQnRmNm9x cUxJIiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiIwMHVjcTNid2o0V25JcTNnejBoNyIsIm5hbWU iOiJQYWRtYS0yIEdvdmluZGFyYWphbHUiLCJsb2NhbGUiOiJlbi1VUyIsInZlciI6MSwiaXNzI joiaHR0cHM6Ly9wYWRtYWdvdmluZGFyYWphbHUub2t0YXByZXZpZXcuY29tL29hdXRoMi9kZWZ hdWx0IiwiYXVkIjoiMG9hZDlydTd0endmNUFqcGIwaDcgIiwiaWF0IjoxNTI0NTk0OTEwLCJle

    HAiOjE1MjQ1OTg1MTAsImp0aSI6IklELklfNUc4RzhWdXowMHJvYl9aSzlja3J0T0pseVdwNzh xMU5naGV2QlJ6dkEiLCJhbXIiOlsicHdkIl0sImlkcCI6IjAwb2NxM2J3aTFoTnpRT3B5MGg3I iwibm9uY2UiOiJhYmMiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJwYWRtYS5nb3ZpbmRhcmFqYWx 1QG9rdGEuY29tIiwiZ2l2ZW5fbmFtZSI6IlBhZG1hIiwibWlkZGxlX25hbWUiOiJLcmlzaG5hI iwiZmFtaWx5X25hbWUiOiJHb3ZpbmRhcmFqYWx1Iiwiem9uZWluZm8iOiJBbWVyaWNhL0xvc19 BbmdlbGVzIiwidXBkYXRlZF9hdCI6MTUyNDU5NDM2MSwiYXV0aF90aW1lIjoxNTI0NTk0OTA3f Q.HvMYW8XbdCf1BWZfHQ1odaAYJjZqKkh1NUkHW0clk6J7pYunn8jllbIp0IhSjcCn6PBIlZPr rE0dkuyjvdHjVI8ALQNwtM7FnIs9H6gCH0oONx4EL4KEf4d_w46qeqsCwMClvNoaE3c2I5kONu JUlaefbnr6Al_y9z5mvLyDynf9IjrOyTPoIrgk9V46l28Aulp4dJhqBtZfpYyVbKrXawHSO5Fv KTDMPBhQgxt0_6PKG7sSkhbMeBicIc35SJJaXt81KSfkYDUp5s1UQ74ATHrtLe7HMU1yp_Kajg YUKxMXO5NiXpeNEHzarAOWzLHblrQcgkpuJbY3KM1HHg&state=xyz1234 The user is redirected back to the redirect_uri with an ID token
  43. ID Token: JWT eyJraWQiOiJiRmxZbmkzLXRhMXFSa0lFellHc2tLeFFRVUJvczZnOU9RQnRmNm9xcUxJIiwiYWxn IjoiUlMyNTYifQ . eyJzdWIiOiIwMHVjcTNid2o0V25JcTNnejBoNyIsIm5hbWUiOiJQYWRtYS0yIEdvdmluZGFyYWph bHUiLCJsb2NhbGUiOiJlbi1VUyIsInZlciI6MSwiaXNzIjoiaHR0cHM6Ly9wYWRtYWdvdmluZGFy YWphbHUub2t0YXByZXZpZXcuY29tL29hdXRoMi9kZWZhdWx0IiwiYXVkIjoiMG9hZDlydTd0endm NUFqcGIwaDcgIiwiaWF0IjoxNTI0NTk0OTEwLCJleHAiOjE1MjQ1OTg1MTAsImp0aSI6IklELklf

    NUc4RzhWdXowMHJvYl9aSzlja3J0T0pseVdwNzhxMU5naGV2QlJ6dkEiLCJhbXIiOlsicHdkIl0s ImlkcCI6IjAwb2NxM2J3aTFoTnpRT3B5MGg3Iiwibm9uY2UiOiJhYmMiLCJwcmVmZXJyZWRfdXNl cm5hbWUiOiJwYWRtYS5nb3ZpbmRhcmFqYWx1QG9rdGEuY29tIiwiZ2l2ZW5fbmFtZSI6IlBhZG1h IiwibWlkZGxlX25hbWUiOiJLcmlzaG5hIiwiZmFtaWx5X25hbWUiOiJHb3ZpbmRhcmFqYWx1Iiwi em9uZWluZm8iOiJBbWVyaWNhL0xvc19BbmdlbGVzIiwidXBkYXRlZF9hdCI6MTUyNDU5NDM2MSwi YXV0aF90aW1lIjoxNTI0NTk0OTA3fQ . HvMYW8XbdCf1BW- ZfHQ1odaAYJjZqKkh1NUkHW0clk6J7pYunn8jllbIp0IhSjcCn6PBIlZPrrE0dkuyjvdHjVI8ALQ NwtM7FnIs9H6gCH0oONx4EL4K-Ef4d_w46qeqsCwMClvNoaE3c2I5-kON- uJUlaefbnr6Al_y9z5mvLyDynf9IjrOyTPoIrgk9V46l28Aulp4dJhqBtZfpYyVbKrXawHSO5FvK TDMPBhQgxt0_6PKG7sSkhbMeBicIc35SJJaXt81KSfkYDUp5s1UQ74ATHrtLe7HMU1yp_KajgYUK xMXO5NiXpeNEHzarAOWzLHblrQcgkpuJbY3KM1HHg header payload signature
  44. Decoded ID Token header . { "sub": "00ucq3bwj4WnIq3gz0h7", "ver": 1,

    "iss": "https://authorization-server.com/oauth2/ausd1nry9hBoyvKrY0h7", "aud": "0oacww4sy8YYS1gOw0h7", "iat": 1524237221, "exp": 1524240821, "nonce": "nonce", "updated_at": 1524606533, "auth_time": 1524606562 } . signature
  45. Verifying the JWT • Fetch the public key of the

    server that issued the token • Verify the signature matches or • Check the token at the userinfo endpoint
  46. OpenID Connect - Authorization Code • Exchange the code for

    an ID Token • No need to verify the signature since the token was obtained via a secure backchannel
  47. Remote ID Token Validation Response { "active": "true", "sub": "0oacww4sy8YYS1gOw0h7",

    "exp": 1524240821, "iat": 1524237221, "iss": "https://auth-server/ausd1nry9hBoyvKrY0h7" }
  48. Authentication Authorization Granting access to your API Getting access to

    data in other systems Logging the user in Making your accounts available in other systems
  49. © Okta and/or its affiliates. All rights reserved. Okta Confidential

    Defining Scopes 97 • Read / Write • Restrict access to sensitive information • e.g. private repos on GitHub • By functionality • e.g. Google Drive, YouTube, Gmail • Billable resources
  50. Pros • Can be revoked by deleting from the database

    • Can easily show a list of active tokens to the user Random String Tokens Cons • Requires storing all active tokens • Resource Server must check the validity with either a DB lookup or HTTP request
  51. Pros • Requires no storage • Better separation of concerns

    (no shared storage between authorization server and resource servers) • Can be validated at the Resource Server without a DB/HTTP lookup Self-Encoded Tokens Cons • Cannot be revoked without storing additional information (defeating the purpose of self-encoded tokens) • Cannot get a list of all active tokens
  52. • Short-lived access tokens, long-lived refresh tokens • Best for

    self-encoded tokens • Limits the risk of leaked tokens • Will annoy developers, so wrap this in an SDK • Short-lived access tokens, no refresh tokens • Limits the ability of apps to work without the user being present • Most likely to frustrate users since they will continually need to log in • Non-expiring access tokens • Easiest for developers • Easiest for users • Highest risk for leaked tokens Access Token Lifetime 108
  53. Access Token Verification The Fast Way The Strong Way Inspect

    the JWT Check the expiration timestamp Validate the cryptographic signature Check the token at the introspection endpoint eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibm FtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImp0aSI6ImI5ZDRhNzViLTA2MDMtN DgxYy1hMjgyLTY3YTk0NDJiNGRkNiIsImlhdCI6MTUzMjQwMDkyMiwiZXhwIjoxNTMy NDA0NTIyfQ.SjYROEt8lZpEOq1eKh3OxRmRk3xttOXZeD5yW8aW2k8 { "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}
  54. Is the application "public"? Does the app have an end

    user? Is your app a SPA or native app? Is the app highly trusted? * Implicit Flow Authorization Code + PKCE Client Credentials Password Authorization Code Yes No SPA Native No Yes No Yes * and no other option is viable Choosing an OAuth Flow
  55. © Okta and/or its affiliates. All rights reserved. Okta Confidential

    Thank You! @aaronpk @oktadev developer.okta.com