Demystifying OAuth
Karl McGuinness
Senior Director, Identity @ Okta
Agenda
Why OAuth?
Breaking down OAuth 2.0
Security & The Enterprise
Pseudo-Authentication
OpenID Connect
Direct Authentication
Password anti-pattern
GET /index.html HTTP/1.1
Host: www.example.com
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
3
Federated Identity
Identity Provider Trust Service Provider
(IdP) (SP)
Obtains Assertion Provides Assertion
End User
4
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
SAML 2.0
OASIS Standard, 15 March 2005
Authentication Request
Protocol
Assertion
6
SAML 2.0 Authentication Request Protocol
7
SAML 2.0 Assertion
<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">
[email protected]
</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>
8
SAML = Web SSO
9
What’s Changed since 2005?
10
Modern and Native Applications
11
Connected Experiences across Devices
12
Simple Web APIs
GET POST PUT DELETE
13
API Economy
14
Delegated Authorization Problem
How can a user authorize an app to access protected data on their behalf?
15
Have you ever seen one of these?
16
17
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 Protecting APIs
and deployment models Since
• Server-to-server apps October 2012
• Browser-based apps
• Mobile/Native apps
• Consoles/TVs
Hotel Key Cards but for Apps
19
OAuth Simplified
1 App requests authorization from User
2 User authorizes App and delivers proof
3 App presents proof of authorization to server to get a Token
4 Token is restricted to only access what the User authorized
for the specific App
20
OAuth 2.0
• Scopes & Consent
• Actors
• Clients
• Tokens
• Authorization Server
• Flows
21
Scopes
• Additive bundles of
permissions asked by client
when requesting a token
• Decouples authorization
Scopes to Allow policy decisions from
enforcement
Scopes to Deny
22
Capturing User Consent
Authorization Grant (Trust of First Use)
23
Actors
Authorization
Server (AS)
Obtains Token
Delegates Uses Token
Resource Client Resource
Owner (RO) Server (RS)
Actors
Authorization
Server (AS)
Obtains Token
Delegates Uses Token
Resource Client Resource
Owner (RO) Server (RS)
Clients
Public Confidential
(Client Identification) (Client Authentication)
26
Clients
Client Registration is the DMV of OAuth
Tokens
Access Token (Required) Refresh Token (Optional)
• Short-lived token used by • Long-lived token that is
Client to access Resource used by Client to obtain
Server (API) new access tokens from
• No client a uthentica tio n Authorization Server
required (Public Clients) • Usually requires
• Optimized for scale and Confidential Clients with
performance authentication
• Usually can’t be revoked • Forces client to rotate
secrets
• Can be revoked
OAuth doesn’t define the format of a token!
28
Authorization Server
Authorization Grant Types are Extensible
Authorization Grant
Authorize Endpoint
(/oauth2/authorize)
Refresh Token
Token Endpoint
(/oauth2/token)
Access Token
Authorization Server
29
Token State Management
Developer Friction
30
Flow Channels
Front Back
Channel Authorization
Channel
Server (AS)
Obtains Token
Delegates Uses Token
Resource Client Resource
Owner (RO) Server (RS)
Front Channel Flow
Authorize via User Agent
Client Resource
Resource Owner starts flow to
1 delegate access to protected
Server (RS)
resource
2
Client sends authorization request 1 4
2 with desired scopes via browser
redirect to Authorize Endpoint on
Authorization Server
User authenticates and consents to
3 Delegated Access (Grant)
Authorization Code Grant or
4 Resource Authorization
Access Token is returned to Client Owner (RO) 3 Server (AS)
via browser redirect
Authorization Request
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
Response HTTP/1.1 302 Found
Location: https://app.example.com/oauth2/callback?
code=MsCeLvIaQm6bTrgtp7&
state=af0ifjsldkj
Note: Parameters are not URL-encoded for example purposes
Back Channel Flow 2
Exchange Grants for Tokens
Client Resource
Client sends access token request to Server (RS)
1 Token Endpoint on Authorization
Server with confidential client 1
credentials or public client id
Exchanges Authorization Code Grant
for Access Token and optionally
Refresh Token
Client accesses protected
2 resource with Access Token
Resource Authorization
Owner (RS) Server (AS)
Token Request
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
Response {
"access_token" : "2YotnFZFEjr1zCsicMWpAA",
"token_type": "Bearer",
"expires_in": 3600,
"refresh_token": "tGzv3JOkF0XG5Qx2TlKWIA",
}
Note: Parameters are not URL-encoded for example purposes
Making Protected Resource Requests
curl -H "Authorization: Bearer 2YotnFZFEjr1zCsicMWpAA" \
https://www.googleapis.com/gmail/v1/users/1444587525/messages
36
OAuth 2.0 Grant Types (Flows)
Implicit (2 Legged) Authorization Code (3 Legged) Client Credential (2 Legged)
• Optimized for browser-only • Front channel flow used by • Optimized for server-only
Public Clients Client to obtain Confidential Clients acting
• Access token returned authorization code grant on behalf of itself or a user
directly from authorization • Back channel flow used by • Back-channel only flow to
request (Front-channel only) Client to exchange obtain an access token
• Does not support refresh authorization code grant for using the Client’s
tokens access token and optionally credentials
refresh token • Supports shared secrets or
• Assumes Resource Owner
and Public Client are on the • Assumes Resource Owner assertions as Client
same device and Client are on separate credentials signed with
devices either symmetric or
• Most vulnerable to security
• Most secure flow as tokens asymmetric keys
threats
never passes through user-
agent
37
OAuth 2.0 Grant Types (Flows)
Resource Owner Password Assertion (2 Legged) Device (Non-Standard)
• Legacy grant type for native • Allows Authorization Server • Optimized for devices that
username/password apps to trust authorization grants do not have access to web-
such as desktop apps from third party such as browsers
• Username/password is SAML IdP (Federation) • User code is returned from
authorization grant to obtain • Assertion is used to obtain authorization request that
access token from access token with token must be redeemed by
Authorization Server request visiting a URL on a device
• Does not support refresh • Does not support refresh with a browser to authorize
to ken s to ken s • Back channel flow used by
• Assumes Resource Owner Client to poll for
and Public Client or on the authorization approval for
same device access token and optionally
refresh token
38
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
Key Enterprise OAuth 2.0 Use Cases
• Decouples authorization policy decisions
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
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
Authorization
Framework?
42
Like WS-Security Security
43
Authorization Framework
Return of Complexity through Extensions
Token Exchange
Draft
Dynamic Client Registration Token Introspection Token Revocation
RFC 7591 RFC 7662 RFC 7009
SAML 2.0 Bearer Assertion Proof of Possession
RFC 7522 Draft
JSON Web Token Bearer Assertion Proof Key for Code Exchange (PKCE)
RFC 7523 RFC 7636
Assertion Framework Bearer Token
RFC 7521 RFC 6750
JSON Web Signature (JWS) JSON Web Encryption (JWE) JSON Web Key (JWK)
RFC 7515 RFC 7516 RFC 7517
JSON Web Token (JWT)
RFC 7519
Simple Authentication and Security Layer (SASL)
RFC 7628
OAuth 2 Framework
RFC 6749
JSON
RFC 7159 44
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
Not an
Authentication
Protocol?
46
OAuth 2.0 as Pseudo-Authentication
As made famous by Facebook Connect and Twitter
Client accessing a • Who is the user (claims)?
https://api.example.com/me • When did the user authenticate?
resource with an access token is • Does the user still have an
not authenticating the user active or expired session?
Access tokens just prove the Client • How did the user authenticate?
was authorized, are opaque, and • Just password or password +
intended to only be consumed by second factor
the Resource Server
47
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
OpenID Connect Authorization Request
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
Response HTTP/1.1 302 Found
Location: https://app.example.com/oauth2/callback?
code=MsCeLvIaQm6bTrgtp7&
state=af0ifjsldkj
Note: Parameters are not URL-encoded for example purposes
OpenID Connect Token Request
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
Response {
"access_token" : "2YotnFZFEjr1zCsicMWpAA",
"token_type": "Bearer",
"expires_in": 3600,
"refresh_token": "tGzv3JOkF0XG5Qx2TlKWIA",
"id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjFlOWdkazcifQ…",
}
Note: Parameters are not URL-encoded for example purposes
JSON Web Token (JWT)
base64url(Header) + “.” + base64url(Claims) + “.” + base64url(Signat ure)
Header
Header Claims {
"alg": "RS256"
eyJhbGciOiJSUzI1NiJ9.eyJpc3MiOiJodH }
RwczovL2V4YW1wbGUub2t0YS5jb20iLC
JzdWIiOiIwMHVncmVuTWVxdllsYTRIVzB Claims
nMyIsImF1ZCI6IncyNTVIRVdpU1U0QXVO {
eEVqZWlqIiwiaWF0IjoxNDQ2MzA1MjgyL "iss": "https://example.okta.com",
CJleHAiOjE0NDYzMDg4ODIsImFtciI6Wy "sub": "00ugrenMeqvYla4HW0g3",
Jwd2QiXSwiYXV0aF90aW1lIjoxNDQ2Mz "aud": "w255HEWiSU4AuNxEjeij",
A1MjgyLCJlbWFpbCI6ImthcmxAZXhhbXB "iat": 1446305282,
sZS5jb20iLCJlbWFpbF92ZXJpZmllZCI6d "exp": 1446308882,
HJ1ZX0.XcNXs4C7DqpR22LLti777AMMV "amr": [
CxM7FjEPKZQnd- "pwd"
AS_Cc6R54wuQ5EApuY6GVFCkIlnfbNm ],
YSbHMkO4H- "auth_time": 1446305282,
L3uoeXVOPQmcqhNPDLLEChj00jQwZD "email": "[email protected]",
jhPD9uBoNwGyiZ9_YKwsRpzbg9NEeY8
Signature "email_verified": true
xEwXJFIdk6SRktTFrVNHAOIhEQsgm8 }
51
OpenID Connect is built on OAuth 2.0
OAuth 2.0 Authorization Server &
1 Discover OIDC Metadata OpenID Connect Provider (OP)
Token Endpoint
2 Get JWT signature keys and 3
optionally dynamically register Authorization Endpoint
Client
/.well-known
1 /webfinger
3 Perform OAuth flow to obtain Client /openid-configuration
id_token and access token (Relying Party)
Client Registration Endpoint
2
Validate JWT id_token JWKS Endpoint
4
Check Session iFrame
5 Get additional user attributes 5
End Session Endpoint
with access token
4
Validate session and/or logout
6 UserInfo Endpoint
6
Validate API Endpoints
(JWT)
ID Token OAuth 2.0 Resource Server
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
Modern OAuth-based Protocols
NAPPS
UMA
OpenID
OAuth Connect
2.0
Q&A
Rate this session
in the mobile app!
Thank You.
