slides-101-edu-sesse-introduction-to-oauth-20-01.pdf

GopalKrishna703039 6 views 116 slides May 06, 2024
Slide 1
Slide 1 of 116
Slide 1
1
Slide 2
2
Slide 3
3
Slide 4
4
Slide 5
5
Slide 6
6
Slide 7
7
Slide 8
8
Slide 9
9
Slide 10
10
Slide 11
11
Slide 12
12
Slide 13
13
Slide 14
14
Slide 15
15
Slide 16
16
Slide 17
17
Slide 18
18
Slide 19
19
Slide 20
20
Slide 21
21
Slide 22
22
Slide 23
23
Slide 24
24
Slide 25
25
Slide 26
26
Slide 27
27
Slide 28
28
Slide 29
29
Slide 30
30
Slide 31
31
Slide 32
32
Slide 33
33
Slide 34
34
Slide 35
35
Slide 36
36
Slide 37
37
Slide 38
38
Slide 39
39
Slide 40
40
Slide 41
41
Slide 42
42
Slide 43
43
Slide 44
44
Slide 45
45
Slide 46
46
Slide 47
47
Slide 48
48
Slide 49
49
Slide 50
50
Slide 51
51
Slide 52
52
Slide 53
53
Slide 54
54
Slide 55
55
Slide 56
56
Slide 57
57
Slide 58
58
Slide 59
59
Slide 60
60
Slide 61
61
Slide 62
62
Slide 63
63
Slide 64
64
Slide 65
65
Slide 66
66
Slide 67
67
Slide 68
68
Slide 69
69
Slide 70
70
Slide 71
71
Slide 72
72
Slide 73
73
Slide 74
74
Slide 75
75
Slide 76
76
Slide 77
77
Slide 78
78
Slide 79
79
Slide 80
80
Slide 81
81
Slide 82
82
Slide 83
83
Slide 84
84
Slide 85
85
Slide 86
86
Slide 87
87
Slide 88
88
Slide 89
89
Slide 90
90
Slide 91
91
Slide 92
92
Slide 93
93
Slide 94
94
Slide 95
95
Slide 96
96
Slide 97
97
Slide 98
98
Slide 99
99
Slide 100
100
Slide 101
101
Slide 102
102
Slide 103
103
Slide 104
104
Slide 105
105
Slide 106
106
Slide 107
107
Slide 108
108
Slide 109
109
Slide 110
110
Slide 111
111
Slide 112
112
Slide 113
113
Slide 114
114
Slide 115
115
Slide 116
116

About This Presentation

oidc concept


Slide Content

@justin _ _ richer
https://bspk.io/
Introduction to OAuth 2.0
Justin Richer
Bespoke Engineering
1

@justin _ _ richer
https://bspk.io/ COURSE VERSION 1.6
Feedback is welcome!
2

@justin _ _ richer
https://bspk.io/
Try the home edition
• OAuth 2 In Action
• Code is open source
• Published March 2017
3

@justin _ _ richer
https://bspk.io/ WHAT IS OAUTH 2.0?
4

@justin _ _ richer
https://bspk.io/
From the spec (RFC6749)
The OAuth 2.0 authorization framework enables a
third-party application to obtain limited access to an
HTTP service, either on behalf of a resource owner by
orchestrating an approval interaction between the
resource owner and the HTTP service, or by allowing
the third-party application to obtain access on its
own behalf.
5

@justin _ _ richer
https://bspk.io/
The good bits
The OAuth 2.0 authorization framework enables a
third-party application to obtain limited access to an
HTTP service, either on behalf of a resource owner by
orchestrating an approval interaction between the
resource owner and the HTTP service, or by allowing
the third-party application to obtain access on its
own behalf.
6

@justin _ _ richer
https://bspk.io/
In other words
OAuth 2.0 is a delegation protocol that lets people
allow applications to access things on their behalf.
7

@justin _ _ richer
https://bspk.io/
Who is involved?
Resource
Owner
Authorization
Server
Protected
Resource
Client
8

@justin _ _ richer
https://bspk.io/
The resource owner
• Has access to some resource or API
• Can delegate access to that resource or API
• Usually has access to a web browser
• Usually is a person
9

@justin _ _ richer
https://bspk.io/
The protected resource
• Web service (API) with security controls
• Protects things for the resource owner
• Shares things on the resource owner’s request
10

@justin _ _ richer
https://bspk.io/
The client application
• Wants to access the protected resource
• Does things on the resource owner’s behalf
• Could be a web server
– But it’s still a “client” in OAuth parlance
– Could also be a native app or JS app
11

@justin _ _ richer
https://bspk.io/
What are we trying to solve?
Resource
Owner
The Goal:
Give the client access
to the protected
resource on behalf of
the resource owner.
Protected
Resource
Client
12

@justin _ _ richer
https://bspk.io/ THIS ISN’T A NEW PROBLEM
People have been solving this for a long time
13

@justin _ _ richer
https://bspk.io/
Steal the keys
Resource
Owner
Copy the resource
owner’s credentials
and replay them to the
protected resource.
Protected
Resource
Client
14

@justin _ _ richer
https://bspk.io/
Ask for the keys
Resource
Owner
Protected
Resource
Client
?
Ask for the resource
owner’s credentials
and replay them to the
protected resource.
15

@justin _ _ richer
https://bspk.io/
Use a universal key
Resource
Owner
A universal key that’s
good for opening the door
no matter who locked it.
Protected
Resource
Client
16

@justin _ _ richer
https://bspk.io/
Service-specific credentials
Resource
Owner
A special password
(or token) that can be
used to access just this
protected resource.
Protected
Resource
Client
17

@justin _ _ richer
https://bspk.io/ WE’RE GETTING CLOSER…
18

@justin _ _ richer
https://bspk.io/
Introducing the Authorization Server
(AS)
Resource
Owner
Authorization
Server
Protected
Resource
Client
The Authorization
Server gives us a
mechanism to bridge
the gap between
the client and the
protected resource
19

@justin _ _ richer
https://bspk.io/
The Authorization Server
• Generates tokens for the client
• Authenticates resource owners (users)
• Authenticates clients
• Manages authorizations
20

@justin _ _ richer
https://bspk.io/
OAuth Tokens
• Represent granted delegated authorities
– From the resource owner to the client for the
protected resource
• Issued by authorization server
• Used by client
– Format is opaque to clients
• Consumed by protected resource
21

@justin _ _ richer
https://bspk.io/
Example OAuth Tokens
• 92d42038006dba95d0c501951ac5b5eb
• 2df029c6-b38d-4083-b8d9-db67c774d13f
• eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiO
iIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiw
iYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RM
HrHDcEfxjoYZgeFONFh7HgQ
• waterbuffalo-elephant-helicopter-argument
22

@justin _ _ richer
https://bspk.io/
You’ve used OAuth
23

@justin _ _ richer
https://bspk.io/ A BRIEF HISTORY OF OAUTH 2.0
24

@justin _ _ richer
https://bspk.io/
Circa 2006
• HTTP password authentication common for
API access
– “Give me your password”
• Internet companies have proprietary solutions
for delegated access
– BBAuth, AuthSub, a few others
25

@justin _ _ richer
https://bspk.io/
The problem
• Two smaller sites want to connect their APIs
for their users
• Both use OpenID for login
– No username/password to pass!
• Neither wants to use a proprietary solution
26

@justin _ _ richer
https://bspk.io/
A new standard is born
• OAuth 1.0 is published independently
– No formal standards body, people just use it
• A session fixation attack is found and fixed
– New version is called OAuth 1.0a
• This community document is standardized as
RFC5849 in the IETF
27

@justin _ _ richer
https://bspk.io/
People start using it
• OAuth 1.0a solves major pain points for many
people in a standard and understandable way
• Google, Yahoo, and others replace their
solutions with the new standard
28

@justin _ _ richer
https://bspk.io/
People start abusing it
• People also decide to start using OAuth for
off-label use cases
– Native applications
– No user in the loop
– Distributed authorization systems
29

@justin _ _ richer
https://bspk.io/
Version 2.0: The framework
• Modularized concepts
• Separated previously conflated components
• Added explicit extensibility points
• Removed pain points of implementers
• Standardized in RFC6749 and RFC6750
30

@justin _ _ richer
https://bspk.io/
What does this mean?
• Instead of a single protocol, OAuth 2.0 defines
common concepts and components and
different ways to mix them together
• It’s not a single standard, it’s a set of
standards for different use cases
31

@justin _ _ richer
https://bspk.io/ WHAT OAUTH ISN’T
32

@justin _ _ richer
https://bspk.io/
Not defined outside of HTTP
• Core protocol defined only for HTTP
• Relies on TLS for securing messages
• There are efforts to use OAuth over non-HTTP
protocols
– GSSAPI
– CoAP
33

@justin _ _ richer
https://bspk.io/
Not an authentication protocol
• Relies on authentication in several places
– Client authentication to token endpoint
– Resource owner authentication at authorization
endpoint
• Doesn’t communicate anything about the user
• However: authentication protocols can be
built using OAuth (OpenID Connect)
34

@justin _ _ richer
https://bspk.io/
No user-to-user delegation
• Allows a user to delegate to a piece of
software but not to another user
• However, multi-party delegation can be built
using OAuth as a core component (UMA)
35

@justin _ _ richer
https://bspk.io/
No authorization processing
• Tokens can represent scopes and other
authorization information
• Processing of this information is up to the
resource server
• However, several methods (UMA, JWT,
introspection) to communicate this
information
36

@justin _ _ richer
https://bspk.io/
No token format
• Token is opaque to the client
• Token needs to be issued by the authorization
server and understood by the resource server,
but they’re free to use whatever format they
want
• However, JSON Web Tokens (JWT) provide a
useful common format
37

@justin _ _ richer
https://bspk.io/
No cryptographic methods
• Core OAuth relies on TLS for protecting
information in transit
• However, other mechanisms like JSON Object
Signing and Encryption (JOSE) define things
that can be used with OAuth
38

@justin _ _ richer
https://bspk.io/
Not a single protocol
• OAuth 2.0 is a framework
– Several core flows plus extensions
• Two things can “implement OAuth” but be
incompatible with each other
• However, code re-use and patterns between
common components makes life simpler
39

@justin _ _ richer
https://bspk.io/ THE AUTHORIZATION CODE FLOW
A deep dive into the canonical OAuth 2.0 transaction
40

@justin _ _ richer
https://bspk.io/
The pieces of OAuth
Resource
Owner
Access
Token
Authorization
Server
Protected
Resource
Client
41

@justin _ _ richer
https://bspk.io/
The authorization code flow
Resource
Owner
Authorization
Server
Protected
Resource
Client
Resource owner’s
credentials
Client’s
credentials
Authorization
code
Access token
42

@justin _ _ richer
https://bspk.io/ TWO FORMS OF COMMUNICATION
43

@justin _ _ richer
https://bspk.io/
The back channel
Resource
Owner
Authorization
Server
Protected
Resource
Client
Back channel uses
direct HTTP connections
between components,
the browser is
not involved
44

@justin _ _ richer
https://bspk.io/
The front channel
Resource
Owner
Authorization
Server
Protected
Resource
Client
Front channel uses
HTTP redirects through
the web browser, no
direct connections
45

@justin _ _ richer
https://bspk.io/
A front channel request/response
Front Channel
Response
Front Channel
Request
Resource
Owner
Authorization
Server
Client
HTTP Redirect
HTTP Redirect
HTTP Request
HTTP Request
HTTP Response
HTTP Response
46

@justin _ _ richer
https://bspk.io/
Why both?
• Separation of information
• Front channel when the user’s involved
• Back channel when they’re not
47

@justin _ _ richer
https://bspk.io/ THE AUTHORIZATION CODE FLOW
Step by step
48

@justin _ _ richer
https://bspk.io/
Authorization Code: Step 1
Resource
Owner
Authorization
Server
Protected
Resource
Client
Client redirects the
resource owner to the
authorization server’s
authorization endpoint
49

@justin _ _ richer
https://bspk.io/
Authorization Code: Step 2
Resource
Owner
Authorization
Server
Protected
Resource
Client
Resource owner
authenticates to the
authorization server
50

@justin _ _ richer
https://bspk.io/
Authorization Code: Step 3
Resource
Owner
Authorization
Server
Protected
Resource
Client
Resource owner
authorizes the client
?
51

@justin _ _ richer
https://bspk.io/
Authorization Code: Step 4
Resource
Owner
Authorization
Server
Protected
Resource
Client
Authorization server
redirects resource owner
back to the client with an
authorization code
52

@justin _ _ richer
https://bspk.io/
Authorization Code: Step 5
Resource
Owner
Authorization
Server
Protected
Resource
Client
Client sends the
authorization code
to the authorization
server’s token endpoint
Client authenticates
using its own credentials
53

@justin _ _ richer
https://bspk.io/
Authorization Code: Step 6
Resource
Owner
Authorization
Server
Protected
Resource
Client
Authorization server
issues an OAuth access
token to the client
54

@justin _ _ richer
https://bspk.io/
Authorization Code: Step 7
Resource
Owner
Authorization
Server
Protected
Resource
Client
Client accesses the
protected resource using
the access token
55

@justin _ _ richer
https://bspk.io/ REFRESH TOKENS
56

@justin _ _ richer
https://bspk.io/
When the user isn’t there
• Access tokens work after the user leaves
– One of the original design goals of OAuth
• What does a client do when the access token
stops working?
– Expiration
– Revocation
57

@justin _ _ richer
https://bspk.io/
Getting a new token
• Repeat the process of getting a token
– Interactive grants: send the resource owner to the
authorization endpoint
• But what if the user’s not there anymore?
58

@justin _ _ richer
https://bspk.io/
Refresh tokens
• Issued alongside the access token
• Used for getting new access tokens
– Presented along with client credentials
– Not good for calling protected resources directly
59

@justin _ _ richer
https://bspk.io/ SCOPES
60

@justin _ _ richer
https://bspk.io/
API Design
• Naïve APIs (like what we built) allow simple
yes/no access
– If your token is good, your request is good
• Smarter APIs divide access
61

@justin _ _ richer
https://bspk.io/
Limited access
• Type of action
– Read, write, delete
• Type of resource
– Photos, metadata, profile
• Time of access
– User is offline, limited number of accesses
62

@justin _ _ richer
https://bspk.io/
OAuth Scopes
• Strings that represent what the token can do
• Client can ask for scopes
• Resource owner approves scopes
• Access token is bound to scopes
63

@justin _ _ richer
https://bspk.io/ OTHER WAYS TO DO OAUTH 2.0
64

@justin _ _ richer
https://bspk.io/
Protocol flexibility
• Canonical use case: web server based
application accessed through a browser
• Authorization code flow is built around this
use case
• What about different kinds of clients?
• What about different kinds of delegation?
65

@justin _ _ richer
https://bspk.io/ IMPLICIT FLOW
66

@justin _ _ richer
https://bspk.io/
Stuff the client into the browser
• Authorization code flow keeps the token out
of the browser and in the client
• But what if the client is inside the browser?
67

@justin _ _ richer
https://bspk.io/
The implicit flow
Resource
Owner
Authorization
Server
Protected
Resource
Client Inside
the Browser
Implicit grant type
uses only the front
channel since the client
is inside the browser
68

@justin _ _ richer
https://bspk.io/ CLIENT CREDENTIALS FLOW
69

@justin _ _ richer
https://bspk.io/
Client acts on its own behalf
• No explicit resource owner
• Replacement for API keys
70

@justin _ _ richer
https://bspk.io/
The client credentials flow
Authorization
Server
Protected
Resource
Client
Client credentials
grant type: Client trades
its own credentials for a
token, uses only the back
channel since the client is
acting on its own behalf
71

@justin _ _ richer
https://bspk.io/ RESOURCE OWNER PASSWORD FLOW
72

@justin _ _ richer
https://bspk.io/
Stealing the password
• Codify the anti-pattern: ask the user for their
credentials and replay them
• Instead of saving the credentials, trade for an
access token
73

@justin _ _ richer
https://bspk.io/
The resource owner password flow
Resource
Owner
Authorization
Server
Protected
Resource
Client
?
Resource owner
credentials grant type:
Client trades username
and password for an OAuth
token over the back channel
74

@justin _ _ richer
https://bspk.io/ HOLD ON!
Didn’t we say it was bad to steal the credentials?
75

@justin _ _ richer
https://bspk.io/ ASSERTION FLOWS
76

@justin _ _ richer
https://bspk.io/
Third-party authorization
• Have a trusted third party hand authorization
to the client
• Client trades that for a token
77

@justin _ _ richer
https://bspk.io/
The assertions flows
Authorization
Server
Assertion provider
Protected
Resource
Client
Client trades a
cryptographically
protected element
(assertion) for a token
78

@justin _ _ richer
https://bspk.io/ DEVICE FLOW
79

@justin _ _ richer
https://bspk.io/
Limited interactivity
• Not every client has a web browser
– Set-top boxes
– Smart devices
• How do we get user interaction?
– Split the pieces
– Use the user to carry the information
80

@justin _ _ richer
https://bspk.io/
The device flow
Device grant type
gives the resource owner
a user code to enter at
the authorization server
Resource
Owner
Authorization
Server
Protected
Resource
Device
Device Code
User Code
Device code
is presented
in the back
channel
81

@justin _ _ richer
https://bspk.io/ NATIVE CLIENTS
82

@justin _ _ richer
https://bspk.io/
What’s a native client?
• Runs on the end user’s system
– Not hosted on a remote web server
– Not executed inside of a web browser
• Can be desktop or mobile
– Local self-contained web server apps qualify
83

@justin _ _ richer
https://bspk.io/
What makes a native client different?
• Functionality lives outside the browser
• Can’t keep secrets from the user
– Especially configure-time secrets
• Requires adaptations to redirect URI to use
the front channel
84

@justin _ _ richer
https://bspk.io/
Dealing with secrets
• Application is copied and run many times
– Shouldn’t give each copy the same secret
• Dynamic client registration
– Give each instance its own ID and secret
• Public clients
– Share an ID and don’t use secrets
85

@justin _ _ richer
https://bspk.io/
Redirect URIs
• Custom URI scheme
– myapp:/oauth_callback?code=ABC123
• Locally hosted web server
– http://localhost:39103/myapp?code=ABC123
• Remote host with push notification
– https://push.example.com/app-942/code=ABC123
86

@justin _ _ richer
https://bspk.io/
Redirect URIs with custom schemes
• Apps need to register for namespace
• Any app can take any namespace
• Malicious apps can try to grab items coming in
on redirect URIs
– Authorization codes (for code flow)
– Tokens (for implicit flow)
87

@justin _ _ richer
https://bspk.io/
PKCE: Sending the challenge
Resource
Owner
Authorization
Server
Protected
Resource
Client
Client generates the
code verifi er and
challenge, includes the
challenge in the front-
channel request to the
authorization server
88

@justin _ _ richer
https://bspk.io/
PKCE: Sending the verifier
Resource
Owner
Authorization
Server
Protected
Resource
Client
Client sends the
verifi er in the back-
channel request to the
authorization server
89

@justin _ _ richer
https://bspk.io/
PKCE: Verifying the challenge
Resource
Owner
Authorization
Server
Protected
Resource
Client
Authorization server
re-generates the
challenge from the
verifi er and compares
it to the challenge
previously sent
90

@justin _ _ richer
https://bspk.io/ MANAGING THE GRANT TYPES
91

@justin _ _ richer
https://bspk.io/
Different use cases
• Authorization code flow: web applications,
some native applications
• Implicit flow: in-browser applications
• Client credentials flow: non-interactive
• Password flow: trusted legacy clients
• Assertion flows: trust frameworks
92

@justin _ _ richer
https://bspk.io/ HOW TO CHOOSE A GRANT TYPE
93

@justin _ _ richer
https://bspk.io/
94
Can the client display a
simple code, image, or
URL to the user?
Is the client acting
on behalf of a
resource owner?
Is the client running
completely inside of a
web browser?
Is the client a native
application?
Yes
Yes
Yes
Yes
Yes
Yes
Yes Yes
No
No
NoNo
Can the resource owner
interact with a web browser
while using the client?
Does the user have a
simple set of credentials
like a password?
Is the client acting
on its own behalf?
Authorization
Code
Add PKCE
or DynReg
Assertion
Resource Owner
Credentials
Client
Credentials
Implicit
Is the client acting
on the authority of a
trusted third party?
Choose the appropriate
OAuth grant type for
the type of application
you’re building
Device

@justin _ _ richer
https://bspk.io/
OpenID Connect
End User
Session at the
Relying Party
Identity Provider
Identity Profi le APIReyling Party
(Application)
End User’s Credentials,
Authorization of the Relying Party
ID Token and
Access Token
Access Token and User Information
95

@justin _ _ richer
https://bspk.io/
Dynamic Client Registration
Resource
Owner
Authorization
Server
Protected
Resource
Client
Request: Display name,
redirect URIs, etc.
Response: Client identifi er,
client secret, etc.
96

@justin _ _ richer
https://bspk.io/
Software statements
• Third party generates an assertion that contains
fixed attributes of the client
– Client can’t change or override what’s in the
statement
• Client presents the statement alongside any
variable attributes
• Server generates unique ID and secret for client
97

@justin _ _ richer
https://bspk.io/
Why use a software statement?
• Many instances of a client software
– Each instance needs its own ID/secret
– All instances should be “recognizable”
• Allow pre-registration across domains
– Software statement from trusted server
– Individual AS registrations for clients
98

@justin _ _ richer
https://bspk.io/ TOKEN INTROSPECTION
99

@justin _ _ richer
https://bspk.io/
OAuth tokens are opaque
• But they’re only opaque to the client
• Protected resource needs to know the token
– What’s it good for?
– Who issued it?
– Is it valid?
100

@justin _ _ richer
https://bspk.io/
How does the resource know?
• Database lookup
– AS and RS are in the same box
• Pack information into the token itself
– Remember JWT?
• Query the AS
– Runtime lookup over the network
101

@justin _ _ richer
https://bspk.io/
“What’s this token good for?”
• Protected resource queries the AS about a
token it received
• AS responds with a JSON structure describing
the token’s status
102

@justin _ _ richer
https://bspk.io/
Introspection trade-offs
• Requires extra credentials (at the RS)
• More network traffic
• Subject to cache consistency problems
– Introspect every time? Only on timeout?
103

@justin _ _ richer
https://bspk.io/ TOKEN REVOCATION
104

@justin _ _ richer
https://bspk.io/
Completing the token lifecycle
• OAuth defines how to get a new token and
refresh a dead token
• Revocation allows clients to proactively throw
away tokens they no longer use
105

@justin _ _ richer
https://bspk.io/
Why revoke tokens?
• Native application being uninstalled
• User selects “log out” or “de-authorize” from
the client (not the AS)
106

@justin _ _ richer
https://bspk.io/
A simple protocol
• Client POSTs to the revocation endpoint
– Token included in body
• Server deletes the token if it finds it
• Server tells the client everything is OK
– Even if no token was deleted, we pretend we did
– Otherwise clients could use this to fish for token
values
• Client throws out its copy of the token
107

@justin _ _ richer
https://bspk.io/ POP, MTLS, AND TOKEN BINDING
108

@justin _ _ richer
https://bspk.io/
Beyond bearer tokens
• Bearer tokens are sent as-is over the wire
• Anyone who has access to the token can use it
• Proof of Possession (PoP) tokens require
cryptographic proof of a key
– Token is transmitted as-is
– Key is used to sign something, not transmitted
itself
109

@justin _ _ richer
https://bspk.io/
Two parts
Token:
Opaque to client
Associated with scopes and RO
Sent as-is to PR
Key:
Known to client
Associated with token
Used to sign request
110

@justin _ _ richer
https://bspk.io/
Mutual TLS
• Client presents certificate to token endpoint
• AS hashes certificate and ties it to token
• Client presents same certificate to RS
• RS hashes certificate and sees if it’s the same
as the one bound to the token
• Client does not have to authenticate with TLS
111

@justin _ _ richer
https://bspk.io/
Token binding
Resource
Owner
Authorization
Server
Use TLS Channel ABC
Here’s a cookie,
only use it on TLS
Channel ABC
Here’s that cookie
again, this is TLS
Channel ABC
112

@justin _ _ richer
https://bspk.io/
A problem with token binding
Resource
Owner
Authorization
Server
Protected
Resource
Client
1
2 3
4
5
113

@justin _ _ richer
https://bspk.io/ WRAPPING UP
114

@justin _ _ richer
https://bspk.io/ SURVEY!
https://www.surveymonkey.com/r/101introOAuth
115

@justin _ _ richer
https://bspk.io/ THANK YOU
http://oauthinaction.com/
116
Tags