OAuth and OpenID Connect in Depth

Read more at https://aaronparecki.com/oauth/

https://oauth2simplified.com

Transcript

1. © Okta and/or its affiliates. All rights reserved. Okta Confidential Aaron Parecki OAuth 2.0 and OpenID Connect in Depth June 2018
2. © Okta and/or its affiliates. All rights reserved. Okta Confidential Aaron Parecki Author, OAuth 2.0 Simplified Maintainer of oauth.net
4. oauth.net
5. © Okta and/or its affiliates. All rights reserved. Okta Confidential Background
6. The Password Antipattern facebook.com 2010
7. 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
8. An open standard for authorization
9. OAuth is a framework for users to authorize applications to act on their behalf
12. but… OAuth doesn’t tell the app who logged in
13. Hotel key cards, but for apps The door doesn’t need to know who you are
14. Who Logged In?
15. Authentication vs Authorization
16. Authentication • Process of verifying the identity of a user. • Making sure the person who is trying to enter into your application is the same person who they claim to be • Usually involves storing and managing passwords
17. Multi-factor Authentication • SMS • TOTP (Google Authenticator) • Mobile Push Notification • FIDO (Yubikey)
18. © Okta and/or its affiliates. All rights reserved. Okta Confidential Part 1: OAuth Clients
19. © Okta and/or its affiliates. All rights reserved. Okta Confidential Obtaining an Access Token
20. 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 it expires
21. Using an Access Token POST /resource/1/update HTTP/1.1 Authorization: Bearer RsT5OjbzRn430zqMLgV3Ia Host: api.authorization-server.com description=Hello+World
22. Registering an Application • Registering an application gives you a client_id • and if the application is not a "public client", then also a client_secret • These identify the application to the service.
23. Client ID and Secret • A "public client" means anything where the client cannot keep strings confidential. • Javascript clients: "view source" • Native apps: can decompile and see strings • No secret is used for these clients, only the ID
24. © Okta and/or its affiliates. All rights reserved. Okta Confidential Web Server Apps Authorization Code Flow
25. 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
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
28. If User Allows https://example.com/auth?code=AUTH_CODE_HERE&state=1234zyx The user is redirected back to the application with an authorization code https://example.com/auth?error=access_denied The user is redirected back to the application with an error code If User Denies
29. Verify State • The application verifies the state matches the expected value
30. 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
31. 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& client_secret=CLIENT_SECRET
32. 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"}
33. 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
34. © Okta and/or its affiliates. All rights reserved. Okta Confidential Javascript Apps Implicit Flow - No Client Secret
35. 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
36. Build the "Log in" link https://authorization-server.com/auth? response_type=token& client_id=CLIENT_ID& redirect_uri=REDIRECT_URI& scope=photos& state=1234zyx
38. If User Allows https://example.com/auth#token=ACCESS_TOKEN The redirect contains an access token in the URL https://example.com/auth#error=access_denied The user is redirected back to the application with an error code If User Denies
39. © Okta and/or its affiliates. All rights reserved. Okta Confidential Mobile Apps PKCE
40. Mobile/native apps also cannot use 
 a client secret!
41. Redirect URLs for Native Apps
42. 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.
43. Redirect URLs for Native Apps Custom URL Scheme: example://redirect App-Claimed URL Pattern https://maps.google.com/*
44. PKCE: Proof Key for Code Exchange RFC 7636: Pioneered by Google • Like an on-the-fly client secret
45. 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 • (For clients that can't support SHA256, include the plaintext verifier as the challenge, and set the method to "plain")
46. 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
47. 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
49. If User Allows example://auth?code=AUTH_CODE_HERE&state=1234zyx The user is redirected back to the application with an authorization code example://auth?error=access_denied The user is redirected back to the application with an error code If User Denies
50. 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
51. 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
52. 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.
53. appauth.io iOS / Android / JavaScript
54. © Okta and/or its affiliates. All rights reserved. Okta Confidential First Party Apps Password Flow
55. 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!
56. © Okta and/or its affiliates. All rights reserved. Okta Confidential Server-to-Server Client Credentials
57. 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
58. © Okta and/or its affiliates. All rights reserved. Okta Confidential Browserless Devices Device Flow
59. Browserless Devices
60. Request a Device Code POST https://authorization-server.com/device client_id=CLIENT_ID First the device requests a device code and user code.
61. © 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.
62. Display the URL and User Code
63. 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" }
64. 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" }
65. 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" }
66. 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" }
67. 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" }
68. 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" }
69. © Okta and/or its affiliates. All rights reserved. Okta Confidential Who Logged In? OpenID Connect
70. OpenID Connect Oauth 2.0
71. 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
72. OpenID Connect Request https://authorization-server.com/auth? response_type=id_token& client_id=CLIENT_ID& redirect_uri=REDIRECT_URI& scope=openid+profile& state=xyz1234
73. © Okta and/or its affiliates. All rights reserved. Okta Confidential
74. © Okta and/or its affiliates. All rights reserved. Okta Confidential
75. 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
76. If User Denies Access https://example.com/#state=xyz1234
 &error=consent_required
 &error_description=User+consent+is+required+fo r+the+following+scopes%3A+%5Bprofile The user is redirected back to the application with an error
77. 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
78. 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
79. Verifying the JWT • Fetch the public key of the server that issued the token • Verify the signature matches
80. • issuer (iss) – does the token originate from the right auth server? • audience (aud) – is the token intended for my application? • expiry time (exp) – has the current time already passed the exp time? • issued at time (iat) – is the current time too far from the issued time? • nonce - does it match to the nonce passed in the request? Validating the Claims
81. OpenID Connect - Authorization Code https://authorization-server.com/auth? response_type=id_token& client_id=CLIENT_ID& redirect_uri=REDIRECT_URI& scope=openid+profile& state=xyz1234
82. 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
83. Remote ID Token Validation POST https://authorization-server.com/introspect token_type_hint=id_token token=ID_TOKEN client_id=CLIENT_ID client_secret=CLIENT_SECRET
84. Remote ID Token Validation Response { "active": "true", "aud": "0oacww4sy8YYS1gOw0h7", "exp": 1524240821, "iat": 1524237221, "iss": "https://auth-server/ausd1nry9hBoyvKrY0h7" }
85. © Okta and/or its affiliates. All rights reserved. Okta Confidential Refresh Tokens
86. What is a Refresh Token? • A special token used to get new access tokens • Requested along with the id_token or access token in the initial step • Usually requires scope: offline_access • Usually not issued to Javascript apps
87. Exchange the Refresh Token for an Access Token POST https://authorization-server.com/token grant_type=refresh_token& refresh_token=REFRESH_TOKEN& redirect_uri=REDIRECT_URI& client_id=CLIENT_ID& client_secret=CLIENT_SECRET
88. New Access Token in the Response { "access_token": "RsT5OjbzRn430zqMLgV3Ia", "expires_in": 3600, "refresh_token": "64d049f8b21191e12522d5d96d5641af5e8" }
89. © Okta and/or its affiliates. All rights reserved. Okta Confidential Part 2: OAuth Servers
90. © Okta and/or its affiliates. All rights reserved. Okta Confidential Components of an OAuth Server
91. Client Registration
92. Client Lifecycle Management
93. • Redirect URLs must be registered per client • Redirect URLs can have a custom scheme (example://redirect) • When an authorization request is made, the server verifies that the redirect URL in the request matches one that is registered to that client ID Redirect URL Registration 93
94. Authenticating the User during Authorization
95. Authenticating the User during Authorization
96. Authenticating the User during Authorization
97. Authenticating the User during Authorization
98. Multifactor Authentication Management
99. Multifactor Authentication Management
100. Authorization Interface
101. Authorization Interface Identify your service Identify the third-party app List the scopes the app is requesting Identify the developer name Show which user is logged in Allow/Cancel buttons
102. List and Manage Authorizations GitHub
103. List and Manage Authorizations GitHub
104. List and Manage Authorizations Google
105. List and Manage Authorizations Google
106. List and Manage Authorizations Twitter
107. © Okta and/or its affiliates. All rights reserved. Okta Confidential OAuth 2.0 Scopes
108. © Okta and/or its affiliates. All rights reserved. Okta Confidential Defining Scopes 108 • Read / Write • Restrict access to sensitive information • e.g. private repos on GitHub • By functionality • e.g. Google Drive, YouTube, Gmail • Billable resources
109. © Okta and/or its affiliates. All rights reserved. Okta Confidential Presenting Scopes to the User 109 • Provide clear and straightforward information • Provide enough detail so the user knows what the application can access • Don't provide too much detail that they are overwhelmed and just click "ok"
112. © Okta and/or its affiliates. All rights reserved. Okta Confidential Allow the user to modify the scopes granted 112
117. © Okta and/or its affiliates. All rights reserved. Okta Confidential Resources
118. jsonwebtoken.io
119. oauth.com/playground
120. oauth.net
121. © Okta and/or its affiliates. All rights reserved. Okta Confidential Q+A
122. © Okta and/or its affiliates. All rights reserved. Okta Confidential Thank you