Let’s understand OAuth 2.0’s core design layer by layer

Barry Chen, 2022.07.30

1

Demo video

• https://youtu.be/TPZ4YEPLpEM

2

Agenda

• The problem that OAuth 2.0 would like to solve
• Core design of different work flows
• No Q&A time

3

4

The problem that OAuth 2.0 would like to solve

A mobile App collecting bank records for personal accounting

5

How can we authorize permission without giving my password ?

6

Before OAuth 2.0

7

Bank 1

Bank 2

Bank 3

Moneybook

Database

Bank ID / Password

User

I want to hack this.

With OAuth 2.0

8

Bank

Authorization

Server

Bank API

Server

Moneybook

User

Login & Agree

access token

use access token �to call API

Bank �password

OAuth 2.0 is designed for us to authorize permission

without leaking our password

9

The core design of OAuth 2.0

10

11

Basic terminology

Implicit Flow

Authorization

Code Flow

with PKCE

Authorization Code Flow

4 Roles in OAuth 2.0

12

13

Resource Owner

Resource Server

Authorization Server

Client

The owner of resource.

Usually it’s end user

The place where we

can retrieve resource

The application who wants to

access your resource

The role who authenticate user

& issue access token

Public v.s. Confidential Client

14

15

Confidential�Client

Able to protect secrets

Definition

Example

API server / server side �rendering application

Public Client

NOT able to protect secrets

Single page application

/ Mobile application

16

Basic terminology

Implicit Flow

Implicit Flow

17

Resource Owner (User)

Client

(Moneybook)

Authorization Server (Bank OAuth)

Resource Server�(Bank API)

1. Use application

2. Send request for

permission

3.UI for login & agreement

4. Enter ID/password & agree

5. Redirect back �with access token �in URL

6.Use access token to access resource

Demo video

• https://youtu.be/0T5D9HApAAs

18

19

20

Devil is in the details

21

Resource Owner (User)

Client

(Moneybook)

Authorization Server (Bank OAuth)

Resource Server�(Bank API)

1. Use application

2. Send request for

permission

3.UI for login & agreement

4. Enter ID/password & agree

5. Redirect back �with access token �in URL

6.Use access token to access resource

Security issues of Implicit Flow

URL can be easily sniffed by any hops over the network, if we don’t use https

22

Client

Router

Local ISP

Local ISP

Router

Server

Security issues of Implicit Flow

• Even though https can protect us, there are still ways to get browser history (e.g. browser extension)

23

24

Any better solution ?

25

Avoid passing

access token in URL ?

26

Authorization Code Flow

27

28

Basic terminology

Implicit Flow

Authorization Code Flow

Authorization Code Flow

29

Resource Owner (User)

Client

(Moneybook)

Authorization Server (Bank OAuth)

Resource Server�(Bank API)

2. Send request for

permission

3.UI for login & agreement

4. Enter ID/password & agree

5. Redirect back with

authorization code �in URL

8 .Use access token to access resource

6. Use

authorization code & client id & client secret to exchange access token (POST)

7. access token

1. Use application

What are client id & client secret ?

To verify your application is the registered client

30

Why do we need �client id & client secret ?

31

Without client id & client secret, those who get authorization code can exchange access token.

​

And the authorization code was brought in URL, so nothing is better than Implicit flow

32

Confidential client is able to protect secret, however for public client …

33

Any better solution ?

34

35

36

Basic terminology

Implicit Flow

Authorization Code Flow

Authorization

Code Flow

with PKCE

Goal:

Without using client secret,

even the malicious attacker get the authorization code, he is not able to exchange access token

37

How does bank

protect us ?

38

39

40

Bank

1. While creating new accounts,

sign signature & cover personal seal

2. While doing important operation,

I need to sign signature or

cover personal seal again

Bank use my signature / seal to verify my identity

​

PKCE works in a similar way

41

PKCE =

Proof Key for Code Exchange

42

43

Client

(Moneybook)

Authorization Server (Bank OAuth)

Send request with �client id & Proof Key

Temporally store� Proof Key

Use authorization code

& client id & Proof Key

to exchange �access token

Verify the � Proof Key

Access token

By this way,

even someone who get my authorization code in URL,

as long as he didn’t get my Proof Key,

he is not able to get access token.�

�(And we don’t use client secret)

44

Authorization Code Flow with Proof Key

45

Resource Owner (User)

Client

(Moneybook)

Authorization Server (Bank OAuth)

Resource Server�(Bank API)

2. Send request with �client id & proof key

4.UI for login & agreement

5. Enter ID/password & agree

6. Redirect back with

authorization code �in URL

10 .Use access token to access resource

7. Use

authorization code & client id & proof key to exchange access token (POST)

9. access token

1. Use application

3. Temporally

store proof key

8. Verify

proof key

Upgrade security by hash algorithm

• Split proof key into 2 asymmetric parts:
• code_verifier: random string
• code_challenge: sha256(code_verifier)

46

Authorization Code Flow with PKCE

Resource Owner (User)

Client

(Moneybook)

Authorization Server (Bank OAuth)

Resource Server�(Bank API)

3. Send request with �client id & code_challenge

5.UI for login & agreement

6. Enter ID/password & agree

7. Redirect back with

authorization code �in URL

11 .Use access token to access resource

8. Use

authorization code & client id & code_verifier to exchange access token (POST)

10. access token

1. Use application

4. Temporally store

code_challenge

9. Verify

code_verifier

with code_challenge

2. Generate code_verifier �& code_challenge

Even attack steal

authorization code and

code challenge,

he is not able to get access token.�

48

49

Basic terminology

Implicit Flow

Authorization Code Flow

Authorization

Code Flow

with PKCE

50

Summary

1. Directly get access token in URL

Implicit

Flow

Authorization

code flow

1. Get authorization code in URL
2. Use authorization code & client id & client secret to exchange access token

Use case

Legacy

Confidential Client

Authorization

code flow with

PKCE

1. Send code challenge in initial request
2. Get authorization code in URL
3. Use authorization code & client id & code verifier to exchange access token

Public Client

OAuth 2.0 is designed for us to authorize permission

without leaking our password

51

Different work flows applies to different scenario, remember to review it before using it.

52

53

Appendix

54

Do you want to know why we have the attack in the beginning video ?

I put it in Appendix

​

Go find it !

Appendix

Why do we have the attack in the beginning video ?

• Because I purposely don’t verify the “state” parameter, I will be under potential risk of CSRF (Cross-Site Request Forgery) attack

​

• Code sample: https://github.com/barry800414/react-google-oauth-example
• Demo website: https://oauth2-csrf-example.netlify.app

55

Appendix - Implicit flow with state parameter details

Resource Owner (User)

Client

(Moneybook)

Authorization Server (Bank OAuth)

Resource Server�(Bank API)

1. Use application

3. Send request with

client id, state

4.UI for login & agreement

5. Enter ID/password & agree

6. Redirect back �with access token &

state in URL

8.Use access token to access resource

2. Generate state, and

store in local storage

7.Verify state from

URL is same as

in local storage

Without this 2 step, our client will accept using any access token.

​

Which may lead user’s data uploaded into wrong place

Thank you for your listening !

57

Barry Chen

https://linktr.ee/barry.chen

You can find my contacts,

slides, and sample code by scanning

the QR code.

Contact me