It seems that OAuth 2.0 is everywhere these days. Whether you are building a hot new single page web application (SPA), a native mobile experience, or just trying to integrate with the API economy, you can't go far without running into the popular authorization framework for REST/APIs and social authentication.
During Oktane15 (https://www.okta.com/oktane15/), Karl McGuinness, our Senior Director of Identity, demystified the powerful, yet often misunderstood, world of OAuth 2.0 and shared details on Okta’s growing support for OpenID Connect.
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
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
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
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
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
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
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
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
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
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