Slide 1

Slide 1 text

© Okta and/or its affiliates. All rights reserved. Okta Confidential Aaron Parecki What the heck is OAuth? July 2018 Chicago / Dallas / San Francisco

Slide 2

Slide 2 text

oauth.net

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

Specs are not good tutorials!

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

The Password Antipattern

Slide 7

Slide 7 text

The Password Antipattern facebook.com 2010

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

How can I let an application access my data without giving it my password?

Slide 10

Slide 10 text

An open standard for authorization

Slide 11

Slide 11 text

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/

Slide 12

Slide 12 text

No content

Slide 13

Slide 13 text

No content

Slide 14

Slide 14 text

but… OAuth doesn’t tell the app who logged in

Slide 15

Slide 15 text

Hotel key cards, but for apps The door doesn’t need to know who you are

Slide 16

Slide 16 text

Who Logged In?

Slide 17

Slide 17 text

Authentication Authorization

Slide 18

Slide 18 text

OAuth 2.0 Terminology • The Application: "Client" • The API: "Resource Server" • The User: "Resource Owner" • Authorization Server • Access Token

Slide 19

Slide 19 text

© Okta and/or its affiliates. All rights reserved. Okta Confidential Part 1: OAuth Clients

Slide 20

Slide 20 text

© Okta and/or its affiliates. All rights reserved. Okta Confidential Obtaining an Access Token

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

© Okta and/or its affiliates. All rights reserved. Okta Confidential Web Server Apps Authorization Code Flow

Slide 26

Slide 26 text

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!

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

Connect with Google

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

No content

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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"}

Slide 37

Slide 37 text

Using an Access Token POST /resource/1/update HTTP/1.1 Authorization: Bearer RsT5OjbzRn430zqMLgV3Ia Host: api.authorization-server.com description=Hello+World

Slide 38

Slide 38 text

© Okta and/or its affiliates. All rights reserved. Okta Confidential Implicit Flow No Client Secret JavaScript / SPA

Slide 39

Slide 39 text

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!

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

No content

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

© Okta and/or its affiliates. All rights reserved. Okta Confidential Mobile Apps PKCE

Slide 46

Slide 46 text

Mobile/native apps also cannot use 
 a client secret!

Slide 47

Slide 47 text

Redirect URLs for Native Apps

Slide 48

Slide 48 text

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.

Slide 49

Slide 49 text

Redirect URLs for Native Apps App-Claimed URL Pattern https://maps.google.com/* Custom URL Scheme: example://redirect

Slide 50

Slide 50 text

PKCE: Proof Key for Code Exchange RFC 7636: Pioneered by Google • Like an on-the-fly client secret

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

No content

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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.

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

appauth.io iOS / Android / JavaScript

Slide 61

Slide 61 text

© Okta and/or its affiliates. All rights reserved. Okta Confidential First Party Apps Password Flow

Slide 62

Slide 62 text

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!

Slide 63

Slide 63 text

© Okta and/or its affiliates. All rights reserved. Okta Confidential Server-to-Server Client Credentials

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

© Okta and/or its affiliates. All rights reserved. Okta Confidential Browserless Devices Device Flow

Slide 66

Slide 66 text

Browserless Devices

Slide 67

Slide 67 text

No content

Slide 68

Slide 68 text

No content

Slide 69

Slide 69 text

Request a Device Code POST https://authorization-server.com/device client_id=CLIENT_ID First the device requests a device code and user code.

Slide 70

Slide 70 text

© 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.

Slide 71

Slide 71 text

Display the URL and User Code

Slide 72

Slide 72 text

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" }

Slide 73

Slide 73 text

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" }

Slide 74

Slide 74 text

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" }

Slide 75

Slide 75 text

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" }

Slide 76

Slide 76 text

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" }

Slide 77

Slide 77 text

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" }

Slide 78

Slide 78 text

No content

Slide 79

Slide 79 text

© Okta and/or its affiliates. All rights reserved. Okta Confidential Who Logged In? OpenID Connect

Slide 80

Slide 80 text

No content

Slide 81

Slide 81 text

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

Slide 82

Slide 82 text

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

Slide 83

Slide 83 text

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

Slide 84

Slide 84 text

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

Slide 85

Slide 85 text

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

Slide 86

Slide 86 text

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

Slide 87

Slide 87 text

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

Slide 88

Slide 88 text

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

Slide 89

Slide 89 text

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

Slide 90

Slide 90 text

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

Slide 91

Slide 91 text

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

Slide 92

Slide 92 text

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

Slide 93

Slide 93 text

Remote ID Token Validation Response { "active": "true", "sub": "0oacww4sy8YYS1gOw0h7", "exp": 1524240821, "iat": 1524237221, "iss": "https://auth-server/ausd1nry9hBoyvKrY0h7" }

Slide 94

Slide 94 text

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

Slide 95

Slide 95 text

© Okta and/or its affiliates. All rights reserved. Okta Confidential Part 2: Building an API

Slide 96

Slide 96 text

Defining Scopes

Slide 97

Slide 97 text

© 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

Slide 98

Slide 98 text

No content

Slide 99

Slide 99 text

No content

Slide 100

Slide 100 text

No content

Slide 101

Slide 101 text

No content

Slide 102

Slide 102 text

No content

Slide 103

Slide 103 text

No content

Slide 104

Slide 104 text

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

Slide 105

Slide 105 text

What type of access tokens? MTQ0NjJkZmQ5OTM2NDE1ZTZjNGZmZjI3 eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOjEwMDAsI mlzcyI6Imh0dHBzOi8vYXV0aG9yaXphdGlvbi1zZXJ2ZXIuY29tIiw iY2lkIjoiaHR0cHM6Ly9leGFtcGxlLWFwcC5jb20iLCJpYXQiOjE0N zAwMDI3MDMsImV4cCI6MTUyOTE3NDg1MSwic2NvcGUiOiJyZWFkIHd yaXRlIn0.QiIrnmaC4VrbAYAsu0YPeuJ992p20fSxrXWPLw-gkFA Random String Self-Encoded (e.g. JWT)

Slide 106

Slide 106 text

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

Slide 107

Slide 107 text

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

Slide 108

Slide 108 text

• 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

Slide 109

Slide 109 text

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}

Slide 110

Slide 110 text

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

Slide 111

Slide 111 text

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

Slide 112

Slide 112 text

jsonwebtoken.io

Slide 113

Slide 113 text

oauth.com/playground

Slide 114

Slide 114 text

oauth.net

Slide 115

Slide 115 text

No content

Slide 116

Slide 116 text

© Okta and/or its affiliates. All rights reserved. Okta Confidential Thank You! @aaronpk @oktadev developer.okta.com