Let’s understand OAuth 2.

0’s
core design layer by layer

Barry Chen, 2022.07.30

1
Demo video

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
Bank 1
Bank ID / Password

Moneybook Bank 2

User
Bank 3

Database

I want to hack this.

7
With OAuth 2.0

Login & Agree Bank

Authorization
Server

Moneybook
User access token

Bank API
use access token Server
to call API
8
OAuth 2.0 is designed for us to
authorize permission
without leaking our password

9
The core design of OAuth
2.0

10
 Authorization
Code Flow
with PKCE

Authorization Code Flow

Implicit Flow

Basic terminology

11
4 Roles in OAuth 2.0

12
 Resource Owner Resource Server
The owner of resource. The place where we
Usually it’s end user can retrieve resource

Client Authorization Server

The application who wants to The role who authenticate user
access your resource & issue access token

13
Public v.s. Confidential Client

14
 Confidential
Public Client
Client

Definition Able to protect secrets NOT able to protect secrets

API server / server side Single page application

Example rendering application / Mobile application

15
 Implicit Flow

Basic terminology

16
 Implicit Flow
Resource Owner Client Authorization Server (Bank Resource Server
(User) (Moneybook) OAuth) (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

17
Demo video

18
19
20
 Devil is in the details
Resource Owner Client Authorization Server (Bank Resource Server
(User) (Moneybook) OAuth) (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

21
Security issues of Implicit Flow

URL can be easily sniffed by any hops over

the network, if we don’t use https

Local ISP Local ISP

Router
Router

Client Server

22
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
Authorization Code Flow

Implicit Flow

Basic terminology

28
 Authorization Code Flow
Resource Owner Client Authorization Server (Bank Resource Server
(User) (Moneybook) OAuth) (Bank API)

1. Use application
2. Send request for
permission
3.UI for login & agreement

4. Enter ID/password & agree

5. Redirect back with

authorization code
in URL

6. Use
authorization code &
client id & client secret to
exchange access token
(POST)
7. access token
8 .Use access token to access resource
29
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
 Authorization
Code Flow
with PKCE

Authorization Code Flow

Implicit Flow

Basic terminology

36
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
 印鑑式樣

1. While creating new accounts,

sign signature & cover personal seal

印鑑式樣

Bank

2. While doing important operation,

I need to sign signature or
cover personal seal again
印鑑式樣

40
Bank use my signature / seal to
verify my identity
PKCE works in a similar way

41
PKCE =
Proof Key for Code Exchange

42
 Client Authorization Server (Bank
(Moneybook) 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

43
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
Resource Owner Client Authorization Server (Bank Resource Server
(User) (Moneybook) OAuth) (Bank API)

1. Use application
2. Send request with
client id & proof key 3. Temporally
4.UI for login & agreement
store proof key

5. Enter ID/password & agree

6. Redirect back with

authorization code
in URL

7. Use
authorization code &
client id & proof key to
exchange access token 8. Verify
(POST) proof key
9. access token
10 .Use access token to access resource
45
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 Client Authorization Server (Bank Resource Server
(User) (Moneybook) OAuth) (Bank API)

1. Use application
2. Generate code_verifier
& code_challenge
3. Send request with
client id & code_challenge 4. Temporally store
5.UI for login & agreement code_challenge
6. Enter ID/password & agree

7. Redirect back with

authorization code
in URL
8. Use
authorization code & client
9. Verify
id & code_verifier to
code_verifier
exchange access token
with
(POST)
code_challenge
10. access token
11 .Use access token to access resource
Even attack steal
authorization code and
code challenge,
he is not able to get access token.

48
 Authorization
Code Flow
with PKCE

Authorization Code Flow

Implicit Flow

Basic terminology

49
 Summary Use case

Implicit 1. Directly get access token in URL Legacy

Flow

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

Authorization
code flow with 1. Send code challenge in initial request
PKCE 2. Get authorization code in URL Public Client
3. Use authorization code & client id &
code verifier to exchange access token

50
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

Do you want
I put it in to know why
Appendix we have the
attack in the
Go find it ! beginning
video ?

54
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 Client Authorization Server (Bank Resource Server

(User) (Moneybook) OAuth) (Bank API)

1. Use application
2. Generate state, and
store in local storage

3. Send request with

client id, state
Without this 2 step, our
4.UI for login & agreement client will accept using
any access token.
5. Enter ID/password & agree
Which may lead user’s
6. Redirect back data uploaded into
with access token & wrong place
state in URL
7.Verify state from
URL is same as
in local storage

8.Use access token to access resource

Thank you for your listening !

57
 Contact me

Barry Chen

https://linktr.ee/barry.chen

You can find my contacts,

slides, and sample code by scanning
the QR code.