1.
Karl McGuinness
Senior Director, Identity @ Okta
Demystifying OAuth

2.
Why OAuth?
Breaking down OAuth 2.0
Pseudo-Authentication
OpenID Connect
Agenda
Security & The Enterprise

3.
Direct Authentication
Password anti-pattern
3
GET /index.html HTTP/1.1
Host: www.example.com
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

4.
Federated Identity
4
Identity Provider
(IdP)
Service Provider
(SP)
End User
Trust
Obtains Assertion Provides Assertion

5.
Identity as Claims
A claim is a statement or assertion that a certain fact applies to something or
somebody
• First Name = ‘Karl’
• Age > 21
• Okta Employee
Issued by an Authority for a Subject (e.g. user, device, etc.)
• Can self-asserted such as Facebook profile or issuer asserted such as Okta Organization
• Explicit trust relationship with an issuer
• Are subject to verification
5

6.
SAML 2.0
OASIS Standard, 15 March 2005
6
Authentication Request
Protocol
Assertion

7.
SAML 2.0 Authentication Request Protocol
7

8.
SAML 2.0 Assertion
8
<Assertion xmlns="urn:oasis:names:tc:SAML:2.0:assertion" ID="b07b804c-­‐7c29-­‐ea16-­‐7300-­‐4f3d6f7928ac" Version="2.0"
IssueInstant="2004-­‐12-­‐05T09:22:05"
<Issuer>https://example.okta.com<Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>
<Subject>
<NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-­‐format:unspecified">
karl@example.com
</NameID>
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
</SubjectConfirmation>
</Subject>
<Conditions NotBefore="2004-­‐12-­‐05T09:17:05" NotOnOrAfter="2004-­‐12-­‐05T09:27:05">
<AudienceRestriction>
<saml:Audience>https://sp.example.com/saml2/sso</saml:Audience>
</AudienceRestriction>
</Conditions>
<AuthnStatement AuthnInstant="2004-­‐12-­‐05T09:22:00" SessionIndex="b07b804c-­‐7c29-­‐ea16-­‐7300-­‐4f3d6f7928ac">
<AuthnContext>
<AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</AuthnContextClassRef>
</AuthnContext>
</AuthnStatement>
<AttributeStatement>
<Attribute Name=“displayName”>
<AttributeValue>Karl McGuinness</AttributeValue>
</Attribute>
</AttributeStatement>
</Assertion>

9.
SAML = Web SSO
9

10.
What’s Changed since 2005?
10

11.
Modern and Native Applications
11

12.
Connected Experiences across Devices
12

13.
Simple Web APIs
GET POST PUT DELETE
13

14.
API Economy
14

15.
Delegated Authorization Problem
How can a user authorize an app to access protected data on their behalf?
15

16.
Have you ever seen one of these?
16

17.
17

18.
OAuth 2.0
Web-scale delegated authorization framework for REST/APIs
• Enables apps to obtain limited access
(scopes) to a user’s data without giving
away a user’s password
• Decouples authentication from
authorization
• Supports multiple use cases
addressing different client capabilities
and deployment models
• Server-to-server apps
• Browser-based apps
• Mobile/Native apps
• Consoles/TVs
Protecting APIs
Since
October 2012

19.
Hotel Key Cards but for Apps
19

20.
OAuth Simplified
App requests authorization from User
20
1
User authorizes App and delivers proof2
App presents proof of authorization to server to get a Token3
Token is restricted to only access what the User authorized
for the specific App
4

21.
OAuth 2.0
21
• Scopes & Consent
• Actors
• Clients
• Tokens
• Authorization Server
• Flows

22.
Scopes
• Additive bundles of
permissions asked by client
when requesting a token
• Decouples authorization
policy decisions from
enforcement
22
Scopes to Deny
Scopes to Allow

23.
Capturing User Consent
Authorization Grant (Trust of First Use)
23

24.
Actors
Resource
Server (RS)
Authorization
Server (AS)
Resource
Owner (RO)
Client
Delegates
Obtains Token
Uses Token

25.
Actors
Resource
Server (RS)
Authorization
Server (AS)
Resource
Owner (RO)
Client
Delegates
Obtains Token
Uses Token

26.
Clients
26
Public
(Client Identification)
Confidential
(Client Authentication)

27.
Clients
Client Registration is the DMV of OAuth

28.
Tokens
28
• Short-lived token used by
Client to access Resource
Server (API)
• No client authentication
required (Public Clients)
• Optimized for scale and
performance
• Usually can’t be revoked
Access Token (Required)
• Long-lived token that is
used by Client to obtain
new access tokens from
Authorization Server
• Usually requires
Confidential Clients with
authentication
• Forces client to rotate
secrets
• Can be revoked
Refresh Token (Optional)
OAuth doesn’t define the format of a token!

29.
Authorization Server
Authorization Grant Types are Extensible
29
Authorize Endpoint
(/oauth2/authorize)
Token Endpoint
(/oauth2/token)
Authorization Server
Authorization Grant
Refresh Token
Access Token

30.
Token State Management
Developer Friction
30

31.
Flow Channels
Resource
Server (RS)
Authorization
Server (AS)
Resource
Owner (RO)
Client
Delegates
Obtains Token
Uses Token
Back
Channel
Front
Channel

32.
Front Channel Flow
Authorize via User Agent
Resource
Server (RS)
Authorization
Server (AS)
4
2
3
1
Resource Owner starts flow to
delegate access to protected
resource
1
Client
2
Client sends authorization request
with desired scopes via browser
redirect to Authorize Endpoint on
Authorization Server
3
User authenticates and consents to
Delegated Access (Grant)
4 Authorization Code Grant or
Access Token is returned to Client
via browser redirect
Resource
Owner (RO)

33.
Authorization Request
GET https://accounts.google.com/o/oauth2/auth?
Scope=gmail.insert gmail.send&
redirect_uri=https://app.example.com/oauth2/callback&
response_type=code&
client_id=812741506391&
state=af0ifjsldkj
HTTP/1.1 302 Found
Location: https://app.example.com/oauth2/callback?
code=MsCeLvIaQm6bTrgtp7&
state=af0ifjsldkj
Request
Response
Note: Parameters are not URL-encoded for example purposes

34.
Back Channel Flow
Exchange Grants for Tokens
Resource
Server (RS)
Authorization
Server (AS)
1
Client
2
Client accesses protected
resource with Access Token
Resource
Owner (RS)
2
Client sends access token request to
Token Endpoint on Authorization
Server with confidential client
credentials or public client id
Exchanges Authorization Code Grant
for Access Token and optionally
Refresh Token
1

35.
Token Request
POST /oauth2/v3/token HTTP/1.1
Host: www.googleapis.com
Content-­‐Type: application/x-­‐www-­‐form-­‐urlencoded
code=MsCeLvIaQm6bTrgtp7&
client_id=812741506391&client_secret={client_secret}&
redirect_uri=https://app.example.com/oauth2/callback&
grant_type=authorization_code
{
"access_token" : "2YotnFZFEjr1zCsicMWpAA",
"token_type": "Bearer",
"expires_in": 3600,
"refresh_token": "tGzv3JOkF0XG5Qx2TlKWIA",
}
Request
Response
Note: Parameters are not URL-encoded for example purposes

36.
Making Protected Resource Requests
curl -H "Authorization: Bearer 2YotnFZFEjr1zCsicMWpAA"
https://www.googleapis.com/gmail/v1/users/1444587525/messages
36

37.
OAuth 2.0 Grant Types (Flows)
37
• Optimized for browser-only
Public Clients
• Access token returned
directly from authorization
request (Front-channel only)
• Does not support refresh
tokens
• Assumes Resource Owner
and Public Client are on the
same device
• Most vulnerable to security
threats
Implicit (2 Legged)
• Front channel flow used by
Client to obtain
authorization code grant
• Back channel flow used by
Client to exchange
authorization code grant for
access token and optionally
refresh token
• Assumes Resource Owner
and Client are on separate
devices
• Most secure flow as tokens
never passes through user-
agent
Authorization Code (3 Legged)
• Optimized for server-only
Confidential Clients acting
on behalf of itself or a user
• Back-channel only flow to
obtain an access token
using the Client’s
credentials
• Supports shared secrets or
assertions as Client
credentials signed with
either symmetric or
asymmetric keys
Client Credential (2 Legged)

38.
OAuth 2.0 Grant Types (Flows)
38
• Legacy grant type for native
username/password apps
such as desktop apps
• Username/password is
authorization grant to obtain
access token from
Authorization Server
• Does not support refresh
tokens
• Assumes Resource Owner
and Public Client or on the
same device
Resource Owner Password
• Allows Authorization Server
to trust authorization grants
from third party such as
SAML IdP (Federation)
• Assertion is used to obtain
access token with token
request
• Does not support refresh
tokens
Assertion (2 Legged)
• Optimized for devices that
do not have access to web-
browsers
• User code is returned from
authorization request that
must be redeemed by
visiting a URL on a device
with a browser to authorize
• Back channel flow used by
Client to poll for
authorization approval for
access token and optionally
refresh token
Device (Non-Standard)

39.
Common OAuth 2.0 Security Issues
• Too many inputs that need validation
• Token hijacking with CSRF
• Always use CSRF token with state parameter to ensure OAuth flow
integrity
• Leaking authorization codes or tokens through redirects
• Always whitelist redirect URIs and ensure proper URI validations
• Token hijacking by switching clients
• Bind the same client to authorization grants and token requests
• Leaking client secrets
• Unbounded & Bearer Tokens
• See draft specification of OAuth Proof-of-Possession Token Extension
39

40.
Key Enterprise OAuth 2.0 Use Cases
• Decouples authorization policydecisions
from enforcement
• Enables the right blend of fine & coarse
grained authorization
• Replaces traditional Web Access
management (WAM) Policies
• Restrict & revoke which apps can access
specific APIs
• Ensure only managed and/or complaint
devices can access specific APIs
• Deep integration with identity
deprovisioning workflow to revoke all
tokens for a user and device
• Federation with an IdP
40

41.
OAuth 2.0 Facts
• Not backward compatible with
OAuth 1.0
• Replaces signatures with HTTPS for
all communication
• Interoperability issues exists as
its not a protocol but rather an
authorization framework
• OAuth 2.0 is not an
authentication protocol
• OAuth 2.0 alone says
absolutely nothing about the
user
41

42.
42
Authorization
Framework?

43.
Like WS-Security Security
43

44.
Authorization Framework
Return of Complexity through Extensions
44
OAuth 2 Framework
RFC 6749
Assertion Framework
RFC 7521
Token Introspection
RFC 7662
Token Revocation
RFC 7009
Dynamic Client Registration
RFC 7591
JSON
RFC 7159
JSON Web Token Bearer Assertion
RFC 7523
Proof Key for Code Exchange(PKCE)
RFC 7636
Simple Authentication and SecurityLayer (SASL)
RFC 7628
Token Exchange
Draft
SAML 2.0 Bearer Assertion
RFC 7522
Proof of Possession
Draft
JSON Web Token (JWT)
RFC 7519
JSON Web Signature (JWS)
RFC 7515
JSON Web Encryption (JWE)
RFC 7516
JSON Web Key (JWK)
RFC 7517
Bearer Token
RFC 6750

45.
Why all the complexity again?
• Enterprise use cases such as federation
• Interoperable tokens that can be signed and encrypted
• Proof-of-Possession tokens that can’t be replayed
• Embedded user agents with unsecure cross-app communication
channels
• Intermediates can capture resource owner credentials, grants, and tokens
• Bindings for non-HTTP transports and legacy protocols such as LDAP
or IMAP as well as constrained devices (IoT)
45

46.
46
Not an
Authentication
Protocol?

47.
OAuth 2.0 as Pseudo-Authentication
As made famous by Facebook Connect and Twitter
Client accessing a
https://api.example.com/me
resource with an access token is
not authenticating the user
Access tokens just prove the Client
was authorized, are opaque, and
intended to only be consumed by
the Resource Server
• Who is the user (claims)?
• When did the user authenticate?
• Does the user still have an
active or expired session?
• How did the user authenticate?
• Just password or password +
second factor
47

48.
OpenID Connect
OAuth 2.0 + Facebook Connect + SAML 2.0 (good parts)
• Extends OAuth 2.0 with new signed
id_token for the Client and UserInfo
endpoint to fetch user attributes
• Provides a standard set of scopes and
claims for identities
• profile
• email
• address
• phone
• Built-in registration, discovery &
metadata for dynamic federations
• Bring Your Own Identity (BYOI)
• Supports high assurance levels and
key SAML use cases (enterprise)
48

49.
OpenID Connect Authorization Request
GET https://accounts.google.com/o/oauth2/auth?
scope=openid email&
redirect_uri=https://app.example.com/oauth2/callback&
response_type=code&
client_id=812741506391&
state=af0ifjsldkj
HTTP/1.1 302 Found
Location: https://app.example.com/oauth2/callback?
code=MsCeLvIaQm6bTrgtp7&
state=af0ifjsldkj
Request
Response
Note: Parameters are not URL-encoded for example purposes

50.
OpenID Connect Token Request
POST /oauth2/v3/token HTTP/1.1
Host: www.googleapis.com
Content-­‐Type: application/x-­‐www-­‐form-­‐urlencoded
code=MsCeLvIaQm6bTrgtp7&
client_id=812741506391&client_secret={client_secret}&
redirect_uri=https://app.example.com/oauth2/callback&
grant_type=authorization_code
{
"access_token" : "2YotnFZFEjr1zCsicMWpAA",
"token_type": "Bearer",
"expires_in": 3600,
"refresh_token": "tGzv3JOkF0XG5Qx2TlKWIA",
"id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjFlOWdkazcifQ…",
}
Request
Response
Note: Parameters are not URL-encoded for example purposes

51.
JSON Web Token (JWT)
base64url(Header) + “.” + base64url(Claims) + “.” + base64url(Signature)
eyJhbGciOiJSUzI1NiJ9.eyJpc3MiOiJodH
RwczovL2V4YW1wbGUub2t0YS5jb20iLC
JzdWIiOiIwMHVncmVuTWVxdllsYTRIVzB
nMyIsImF1ZCI6IncyNTVIRVdpU1U0QXVO
eEVqZWlqIiwiaWF0IjoxNDQ2MzA1MjgyL
CJleHAiOjE0NDYzMDg4ODIsImFtciI6Wy
Jwd2QiXSwiYXV0aF90aW1lIjoxNDQ2Mz
A1MjgyLCJlbWFpbCI6ImthcmxAZXhhbXB
sZS5jb20iLCJlbWFpbF92ZXJpZmllZCI6d
HJ1ZX0.XcNXs4C7DqpR22LLti777AMMV
CxM7FjEPKZQnd-
AS_Cc6R54wuQ5EApuY6GVFCkIlnfbNm
YSbHMkO4H-
L3uoeXVOPQmcqhNPDLLEChj00jQwZD
jhPD9uBoNwGyiZ9_YKwsRpzbg9NEeY8
xEwXJFIdk6SRktTFrVNHAOIhEQsgm8
51
{
"alg": "RS256"
}
{
"iss": "https://example.okta.com",
"sub": "00ugrenMeqvYla4HW0g3",
"aud": "w255HEWiSU4AuNxEjeij",
"iat": 1446305282,
"exp": 1446308882,
"amr": [
"pwd"
],
"auth_time": 1446305282,
"email": "karl@example.com",
"email_verified": true
}
Header Claims
Signature
Header
Claims

52.
OpenID Connect is built on OAuth 2.0
Validate
(JWT)
ID Token
Token Endpoint
Authorization Endpoint
/.well-known
/webfinger
/openid-configuration
Client Registration Endpoint
JWKS Endpoint
Check Session iFrame
End Session Endpoint
UserInfo Endpoint
OAuth 2.0 Authorization Server &
OpenID Connect Provider (OP)
OAuth 2.0 Resource Server
API Endpoints
Client
(Relying Party)
1
2
3
5
6
4
1 Discover OIDC Metadata
2 Get JWT signature keys and
optionally dynamically register
Client
3 Perform OAuth flow to obtain
id_token and access token
4 Validate JWT id_token
5 Get additional user attributes
with access token
6 Validate session and/or logout

53.
Summary
• OAuth 2.0 is an authorization framework for delegated access to APIs
• Clients request scopes that Resources Owners authorize (consent)
• Authorization grants are exchanged for an access token and optionally refresh token
• Multiple flows to address varying Client capabilities and authorization scenarios
• Use JSON Web Tokens (JWT) for structured tokens between Authorization Server and
Resource Server
• OAuth 2,0 has a very large security surface area
• Use a secure toolkit and remember to validate all inputs!
• OAuth 2.0 is not an authentication protocol
• OpenID Connect extends OAuth 2.0 for authentication scenarios
“SAML with curly-braces”
53

54.
Modern OAuth-based Protocols
OAuth
2.0
OpenID
Connect
UMA
NAPPS

55.
Q&A

56.
Rate this session
in the mobile app!

57.
Thank You.