OAuth all the things! An Introduction to OAuth

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

@aaronpk oauth.net

Slide 4

Slide 4 text

@aaronpk

Slide 5

Slide 5 text

Slide 6

Slide 6 text

@aaronpk The Password Antipattern facebook.com 2010

Slide 7

Slide 7 text

@aaronpk 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 8

Slide 8 text

@aaronpk An open standard for authorization

Slide 9

Slide 9 text

@aaronpk OAuth is a framework for users to authorize applications to act on their behalf

Slide 10

Slide 10 text

@aaronpk

Slide 11

Slide 11 text

@aaronpk

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

@aaronpk Authentication vs Authorization

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

@aaronpk 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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

@aaronpk 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.

Slide 20

Slide 20 text

@aaronpk 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

Slide 21

Slide 21 text

Slide 22

Slide 22 text

@aaronpk Authorization Server Resource Server The Best App Ever accounts.google.com contacts.google.com FriendFinder The User’s Computer

Slide 23

Slide 23 text

@aaronpk Authorization Server Resource Server 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 write access to my account Authz: 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 Authz: Here is an access token! App: Please let me access this user’s data with this access token!

Slide 24

Slide 24 text

@aaronpk 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 25

Slide 25 text

@aaronpk 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 26

Slide 26 text

@aaronpk

Slide 27

Slide 27 text

@aaronpk 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

Slide 28

Slide 28 text

@aaronpk Verify State • The application verifies the state matches the expected value

Slide 29

Slide 29 text

@aaronpk 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 30

Slide 30 text

@aaronpk 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

Slide 31

Slide 31 text

@aaronpk 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 32

Slide 32 text

@aaronpk 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 33

Slide 33 text

Slide 34

Slide 34 text

@aaronpk 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 35

Slide 35 text

@aaronpk 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 36

Slide 36 text

@aaronpk

Slide 37

Slide 37 text

@aaronpk 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

Slide 38

Slide 38 text

@aaronpk But… use the Implicit Flow sparingly! https://developer.okta.com/blog/2018/05/24/what-is-the-oauth2-implicit-grant-type https://oauth.net/2/grant-types/implicit/

Slide 39

Slide 39 text

Slide 40

Slide 40 text

@aaronpk Mobile/native apps also cannot use   a client secret!

Slide 41

Slide 41 text

@aaronpk Redirect URLs for Native Apps

Slide 42

Slide 42 text

@aaronpk 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 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

@aaronpk 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")

Slide 46

Slide 46 text

@aaronpk 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 47

Slide 47 text

@aaronpk 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 48

Slide 48 text

@aaronpk

Slide 49

Slide 49 text

@aaronpk 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

Slide 50

Slide 50 text

@aaronpk 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 51

Slide 51 text

Slide 52

Slide 52 text

@aaronpk 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 53

Slide 53 text

@aaronpk appauth.io iOS / Android / JavaScript

Slide 54

Slide 54 text

Slide 55

Slide 55 text

@aaronpk 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 56

Slide 56 text

Slide 57

Slide 57 text

@aaronpk 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 58

Slide 58 text

Slide 59

Slide 59 text

@aaronpk Browserless Devices

Slide 60

Slide 60 text

@aaronpk 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 61

Slide 61 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 62

Slide 62 text

@aaronpk Display the URL and User Code

Slide 63

Slide 63 text

@aaronpk 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 64

Slide 64 text

@aaronpk 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 65

Slide 65 text

Slide 66

Slide 66 text

Slide 67

Slide 67 text

Slide 68

Slide 68 text

Slide 69

Slide 69 text

Slide 70

Slide 70 text

@aaronpk 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

Slide 71

Slide 71 text

@aaronpk 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

Slide 72

Slide 72 text

@aaronpk New Access Token in the Response { "access_token": "RsT5OjbzRn430zqMLgV3Ia", "expires_in": 3600, "refresh_token": "64d049f8b21191e12522d5d96d5641af5e8" }

Slide 73

Slide 73 text

Slide 74

Slide 74 text

Slide 75

Slide 75 text

@aaronpk Client Registration

Slide 76

Slide 76 text

@aaronpk Authenticating the User during Authorization

Slide 77

Slide 77 text

@aaronpk Authenticating the User during Authorization

Slide 78

Slide 78 text

@aaronpk Authenticating the User during Authorization

Slide 79

Slide 79 text

@aaronpk Multifactor Authentication Management

Slide 80

Slide 80 text

@aaronpk Multifactor Authentication Management

Slide 81

Slide 81 text

@aaronpk Authorization Interface

Slide 82

Slide 82 text

@aaronpk 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

Slide 83

Slide 83 text

@aaronpk List and Manage Authorizations GitHub

Slide 84

Slide 84 text

@aaronpk List and Manage Authorizations GitHub

Slide 85

Slide 85 text

@aaronpk List and Manage Authorizations Google

Slide 86

Slide 86 text

@aaronpk List and Manage Authorizations Google

Slide 87

Slide 87 text

@aaronpk List and Manage Authorizations Twitter

Slide 88

Slide 88 text

Slide 89

Slide 89 text

© Okta and/or its affiliates. All rights reserved. Okta Confidential Defining Scopes !89 • Read / Write • Restrict access to sensitive information • e.g. private repos on GitHub • By functionality • e.g. Google Drive, YouTube, Gmail • Billable resources

Slide 90

Slide 90 text

© Okta and/or its affiliates. All rights reserved. Okta Confidential Presenting Scopes to the User !90 • 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"

Slide 91

Slide 91 text

@aaronpk

Slide 92

Slide 92 text

@aaronpk

Slide 93

Slide 93 text

Slide 94

Slide 94 text

@aaronpk

Slide 95

Slide 95 text

@aaronpk

Slide 96

Slide 96 text

@aaronpk

Slide 97

Slide 97 text

@aaronpk

Slide 98

Slide 98 text

Slide 99

Slide 99 text

@aaronpk oauth.net

Slide 100

Slide 100 text

@aaronpk oauth.com/playground

Slide 101

Slide 101 text

@aaronpk oauth2simplified.com

Slide 102

Slide 102 text

Thanks! oauth.net oauth2simplified.com the spec, links to libraries, docs my book! Print, PDF, ePub aaronpk.com @aaronpk