What the Heck is OAuth?

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

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. oauth.net
4. Specs are not good tutorials!
5. © Okta and/or its affiliates. All rights reserved. Okta Confidential Background
6. The Password Antipattern
7. The Password Antipattern facebook.com 2010
8. 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
9. How can I let an application access my data without giving it my password?
10. An open standard for authorization
11. 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/
14. but… OAuth doesn’t tell the app who logged in
15. Hotel key cards, but for apps The door doesn’t need to know who you are
16. Who Logged In?
17. Authentication Authorization
18. OAuth 2.0 Terminology • The Application: "Client" • The API: "Resource Server" • The User: "Resource Owner" • Authorization Server • Access Token
19. © Okta and/or its affiliates. All rights reserved. Okta Confidential Part 1: OAuth Clients
20. © Okta and/or its affiliates. All rights reserved. Okta Confidential Obtaining an Access Token
21. 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
22. 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
23. 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
24. 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
25. © Okta and/or its affiliates. All rights reserved. Okta Confidential Web Server Apps Authorization Code Flow
26. 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!
27. 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
28. Connect with Google
29. 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
30. 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
32. 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
33. 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
34. 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
35. 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
36. 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"}
37. Using an Access Token POST /resource/1/update HTTP/1.1 Authorization: Bearer RsT5OjbzRn430zqMLgV3Ia Host: api.authorization-server.com description=Hello+World
38. © Okta and/or its affiliates. All rights reserved. Okta Confidential Implicit Flow No Client Secret JavaScript / SPA
39. 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!
40. 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
41. 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
43. 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
44. 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
45. © Okta and/or its affiliates. All rights reserved. Okta Confidential Mobile Apps PKCE
46. Mobile/native apps also cannot use 
 a client secret!
47. Redirect URLs for Native Apps
48. 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.
49. Redirect URLs for Native Apps App-Claimed URL Pattern https://maps.google.com/* Custom URL Scheme: example://redirect
50. PKCE: Proof Key for Code Exchange RFC 7636: Pioneered by Google • Like an on-the-fly client secret
51. 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
52. 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
53. 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
55. 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
56. 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
57. 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
58. 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.
59. 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
60. appauth.io iOS / Android / JavaScript
61. © Okta and/or its affiliates. All rights reserved. Okta Confidential First Party Apps Password Flow
62. 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!
63. © Okta and/or its affiliates. All rights reserved. Okta Confidential Server-to-Server Client Credentials
64. 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
65. © Okta and/or its affiliates. All rights reserved. Okta Confidential Browserless Devices Device Flow
66. Browserless Devices
69. Request a Device Code POST https://authorization-server.com/device client_id=CLIENT_ID First the device requests a device code and user code.
70. © 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.
71. Display the URL and User Code
72. 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" }
73. 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" }
74. 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" }
75. 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" }
76. 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" }
77. 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" }
79. © Okta and/or its affiliates. All rights reserved. Okta Confidential Who Logged In? OpenID Connect
81. 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
82. 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
83. © Okta and/or its affiliates. All rights reserved. Okta Confidential
84. © Okta and/or its affiliates. All rights reserved. Okta Confidential
85. 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
86. 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
87. 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
88. 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
89. 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
90. OpenID Connect - Authorization Code https://authorization-server.com/auth? response_type=code& client_id=CLIENT_ID& redirect_uri=REDIRECT_URI& scope=openid+profile& state=xyz1234
91. 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
92. 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
93. Remote ID Token Validation Response { "active": "true", "sub": "0oacww4sy8YYS1gOw0h7", "exp": 1524240821, "iat": 1524237221, "iss": "https://auth-server/ausd1nry9hBoyvKrY0h7" }
94. 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
95. © Okta and/or its affiliates. All rights reserved. Okta Confidential Part 2: Building an API
96. Defining Scopes
97. © 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
104. © Okta and/or its affiliates. All rights reserved. Okta Confidential Access Tokens
105. What type of access tokens? MTQ0NjJkZmQ5OTM2NDE1ZTZjNGZmZjI3 eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOjEwMDAsI mlzcyI6Imh0dHBzOi8vYXV0aG9yaXphdGlvbi1zZXJ2ZXIuY29tIiw iY2lkIjoiaHR0cHM6Ly9leGFtcGxlLWFwcC5jb20iLCJpYXQiOjE0N zAwMDI3MDMsImV4cCI6MTUyOTE3NDg1MSwic2NvcGUiOiJyZWFkIHd yaXRlIn0.QiIrnmaC4VrbAYAsu0YPeuJ992p20fSxrXWPLw-gkFA Random String Self-Encoded (e.g. JWT)
106. 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
107. 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
108. • 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
109. 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}
110. 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
111. © Okta and/or its affiliates. All rights reserved. Okta Confidential Resources
112. jsonwebtoken.io
113. oauth.com/playground
114. oauth.net
116. © Okta and/or its affiliates. All rights reserved. Okta Confidential Thank You! @aaronpk @oktadev developer.okta.com