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">
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>
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":  "karl@example.com",
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.