OAuth Base Camp

OAuth Base Camp
Lecture, Karlsruhe Institute of Technology, 2013-05-22
Dr. Oliver Pfaff
© iC Consult GmbH 2013 - Dr. Oliver Pfaff

Preface
IT-Security - A Jigsaw Puzzle with Many Pieces
Authorization
▶ Today’s focus: authorization
 For individually owned Web
resources
 Discretionally managed by
their resource owners
▶ The discussed mechanism
addresses a key use case
 It needs to be combined with
other security mechanisms
to deliver sound solutions -
engineered security
 It needs to be implemented
with care to avoid eventual
breaches – secure engineering
Single-
Sign-On
Infrastructure
Authenticity
Key
management
Threats/Risks
Confidentiality
User/entity
authentication
Coding

Contents
▶ User authorization
▶ OAuth
▶ Demonstration
▶ Key observation
▶ Generalizations
 User authentication
 App authentication
 Grant types
 Kinds of tokens
 IAM styles
▶ Conclusions

User Authorization
Considered Use Case
▶ Individual, access-protected resources used by third-party providers
 In the interest of resource owners, adding value for them
 Not: legal entity-owned resources or public resources
▶ Examples:
 Post to your feed at Facebook
 Get your contacts or calendar from Google
 Get your location information from a mobile provider
 …
You
Application
Your resources
Web container
HTTP
HTML
HTML
Web
browser
Your
user agent
Your service provider
Application
Web container
HTML
HTTP
Third-party provider
,JSON,XML

User Authorization
Relevance of this Use Case
▶ Web APIs are a key driver behind current innovation in the Internet
 Mindset: others might have cool ideas about what could be done with your
assets – facilitate their integration
 Examples: Web API directory
 Buzzwords: API economy, mash-ups, composite applications, REST…
▶ Ability to work with individual, access-protected resources is a key concern
 With public resources only, the potential behind Web APIs would get
exhausted quickly
 Fundamentally important

User Authorization
Coverage for this Use Case
▶ Chickens – some birds just don’t fly:
 IT-security: fiddle with authentication credentials
• Assign end-user credentials to clients in a mashup (which authn
themselves as end-users)
• Assign service provider credentials to them (which authn end-users
themselves and call as super-users)
 IAM: use enterprise authorization approaches
• Utilize long-lived authorization policy objects established a-priori and
managed out-of-band (from the browsing sessions of users)
 IT-security and IAM mechanisms as known/established until mid of last decade
not do the desired trick

User Authorization
How to Fill the Gap?
▶ Real-world analogy: valet parking keys
 Master key: all vehicle features
 Valet key: opens doors, starts engine but does not open luggage/glove
compartments, limits speed…
▶ Useful when trusting (discretionary powers) an attendant (third-party) to
park (limited use) the own car (resource)
▶ A Web-equivalent to valet parking keys would help: means that allow owners
of Web resources to delegate resource access to third-parties
 in discretionary fashion
 and a constrained way (time, functional scope…)

OAuth
Overview
▶ OAuth defines a resource authorization protocol that allows resource owners to
delegate resource access rights to third-parties in a discretionary fashion with
a limited functionality, for a limited time
▶ The OAuth specifications are developed by the IETF User Authorization
Protocol (oauth) working group:
 The OAuth 2.0 Authorization Framework RFC 6749, 2012
 The OAuth 2.0 Authorization Framework: Bearer Token Usage RFC 6750, 2012
 An IETF URN Sub-Namespace for OAuth RFC 6755, 2012
 OAuth 2.0 Threat Model and Security Considerations RFC 6819, 2013
 Plus several draft documents – work-in-progress
▶ The specifications care about simple things:
 How to obtain a token to access resources?
 How to use such tokens?
▶ Note: in the following OAuth 2.0 is considered. The term ‘OAuth’ refers to version
2.0 by default (predecessor: The OAuth 1.0 Protocol RFC 5849, 2010)

OAuth
(Super)Simplified
▶ With 3 assumptions:
 Individual, access-protected resources
 Third-party consumers
 HTTP
▶ in 1 sentence: 3-party resource authorization protocol allowing resource owners
to delegate access rights dynamically and in-band (with their browsing sessions)
▶ and in 1 diagram:
Resource
owner
Resource
provider
Resource
consumer
3. Present user authz
1. Request user authz
2. Establish user authz

OAuth
The First Trick – User-Managed Authorization
OAuth-protected
resource endpoint
Resource
owner
Resource consumer
Resource providerAuthorization server
Post/Get/
Put/Delete with
access_token
200 OK with
<Resource>
Resource
client
30x Redirect with
code (URL query param)
Bold: objects/endpoints specified by OAuth
User authn
and consent
dialogues
: exchanges specified by OAuth
Authorization
endpoint
30x Redirect
with scope
(URL query param)
Redirection
endpoint
Token
endpoint
Post with client
creds, code (application/
x-www-form-urlencoded)
200 OK with
access_token
(application/json)
Token
client

OAuth
A User Authentication Protocol?
▶ Resource consumers do not get information about the
 Authentication (method, time, authority…) established for the current user
 Identity (identifiers, attributes, affiliations…) of the current user
▶ They can not challenge for certain methods of authentication, levels of assurance…
 OAuth does not define a protocol for user authentication in distributed
systems (attention: this refers to the native authorization code grant shown
above; things gets more subtle with OAuth extensions and additional grants)

OAuth
Core Abstractions
▶ Authorization grants: credentials that refer to resource owner’s authorization
and that are presented in requests to OAuth token endpoints
▶ Protocol endpoints (RFC 6749):
 Authorization endpoint
 Token endpoint
 Redirection endpoint
▶ Protocol messages (RFC 6749):
 Authorization requests and responses - via HTTP redirection
• Request parameters: response_type, scope etc.
• Response parameters: code etc.
 Token requests and responses
• Request parameters: grant_type, scope etc.
• Response parameters: access_token etc.
▶ Resource request authentication:
 Bearer (RFC 6750)
 MAC (draft-ietf-oauth-v2-http-mac-03.txt)
 OAuth (RFC 5849)

OAuth
Extension Points
▶ Authorization grants: new grants e.g. JWT/SAML 2.0 bearer assertions defined
by OAuth (draft-ietf-oauth-jwt-bearer-05.txt, draft-ietf-oauth-saml2-bearer-16.txt)
▶ Protocol endpoints: new endpoints e.g.
 TokenRevocation for token revocation purposes defined by OAuth (draft-ietf-
oauth-revocation-07.txt)
 Introspection for discovering token metadata (draft-richer-oauth-
introspection-04.txt)
 TokenInfo for token validation and discovery purposes provided by e.g.
Google (https://accounts.google.com/o/oauth2/tokeninfo)
▶ Protocol messages:
 New messages e.g. revocation request/response defined for token revocation
purposes by OAuth (draft-ietf-oauth-revocation-07.txt)
 New parameters e.g. request resp. id_token in authorization request resp.
authorization/token response messages defined by OIDC for user
authentication purposes
 New values e.g. id_token resp. profile, offline_access of the OAuth-
defined response_type resp. scope parameters defined by OIDC
▶ Resource request authentication: new schemes

OAuth
Revocation
▶ Of OAuth tokens:
 Short-lived objects to access resources
 Supporting their revocation is based on an additional endpoint and is optional
(draft-ietf-oauth-revocation-07.txt implementations should support the
revocation of access tokens)
▶ Of OAuth refresh tokens:
 Long-lived objects to refresh OAuth tokens
 Supporting their revocation is based on an additional endpoint and is optional
(draft-ietf-oauth-revocation-07.txt implementations must support the
revocation of refresh tokens)
▶ Of objects storing granted authorizations by end users:
 Long-lived objects governing OAuth tokens/refresh tokens issuance
 Such objects are not specified by OAuth. It is common practice to provide
Web UIs for revoking these objects. For instance:
• Google: Authorized Access to your Google Account
• Facebook: App requests and activity

OAuth
Adoption
▶ AT&T: AT&T APIs use OAuth 2.0
▶ Facebook: Graph API uses OAuth 2.0
▶ Flickr: Flickr APIs use OAuth 1.x
▶ Google: Google APIs use OAuth 2.0
▶ LinkedIn: LinkedIn API supports OAuth 2.0 and 1.x
▶ Microsoft:
 Live Connect uses OAuth 2.0,
 Windows Azure esp. Windows Azure AD Access Control supports OAuth 2.0
▶ Salesforce: Force.com and Salesforce.com APIs use OAuth 2.0
▶ Telefonica: BlueVia APIs use OAuth 2.0 as well as OAuth 1.x
▶ Tumblr: Tumblr API uses OAuth 1.x
▶ Twitter: Twitter API uses OAuth 1.x
▶ Xing: Xing API uses OAuth 1.x
▶ Yahoo: Yahoo APIs use OAuth 1.x
▶ Yammer: Yammer APIs use OAuth 2.0
▶ …and many others. Note that some do abstain:
 Amazon Web Services: "Do you support SAML or OAuth? Not at this time…"

Demonstration
Accessing OAuth-Protected Web APIs at Google
▶ Chosen OAuth-protected resource:
 User info endpoint: https://www.googleapis.com/oauth2/v1/userinfo
▶ OAuth authz server:
 Token endpoint: https://accounts.google.com/o/oauth2/token
 Authz endpoint: https://accounts.google.com/o/oauth2/auth
▶ Resource consumer: DIY clients embedded in an own Web application:
 Servlet: GoogleConnectServlet
 Embedded clients: UserInfoServiceClient, OAuthTokenServiceClient
 Third-party libraries: esp. Apache HttpClient, Google GSON
▶ Demonstration approach:
 Common client code prepared upfront
 OAuth-specific code evolves stepwise

302 Found
HTTP GetHTTP PostHTTP Get
Demonstration
Web APIs that Will Be Called
Web
browser
Google
Token
endpoint
Authorization
endpoint
OAuth-protected
UserInfo endpoint
https://accounts.google.com/
o/oauth2/auth
https://www.googleapis.com/
oauth2/v1/userinfo
https://accounts.google.com/
o/oauth2/token
Authorization server
GoogleConnectServlet
UserInfo
ServiceClient
OAuthToken
ServiceClient
Redirection
endpoint

Demonstration
Implementation Remark
▶ To keep the code compact, the same servlet class is used to implement:
 OAuth redirection endpoint: respond to subsequent requests from user
agents – triggered by redirects from OAuth authorization endpoints:
GET /…/GoogleConnectServlet?code=4VrjQAl…&state=79e26d… HTTP/1.1
 OAuth enforcement point: respond to initial requests from user agents –
triggered by user action:
GET /…/GoogleConnectServlet HTTP/1.1
▶ This results in following code skeleton:
if (needsUserLogin(httpServletRequest, httpServletResponse)) {
try {
// Provides the OAuth redirection endpoint
// Completes OAuth user authorization exchange
// Conducts OAuth token and UserInfo exchanges
} catch (UserAuthorizationNeededException e1) {
// Provides the OAuth enforcement point
// Initiates OAuth user authorization exchange
} catch (OtherException e2) {
// Take care
}
// Do work for authn user
}

Demonstration
Important Links for this Example
▶ User-facing links:
 Manage granted authorizations:
https://accounts.google.com/b/0/IssuedAuthSubTokens
▶ Developer-facing links:
 Manage Google API clients: https://code.google.com/apis/console/
 Using OAuth to access Google APIs:
http://code.google.com/apis/accounts/docs/OAuth2.html
 User info Web API documentation:
• For Web applications as callers:
https://developers.google.com/accounts/docs/OAuth2Login
• For AJAX clients/mobile apps as callers:
https://developers.google.com/accounts/docs/OAuth2UserAgent
 Cryptographic checksum validation keys (concerns ID Token objects):
https://www.googleapis.com/oauth2/v1/certs

Demonstration
Ditto for Facebook
▶ User-facing links:
 Manage granted authorizations:
http://www.facebook.com/settings?tab=notifications&section=application_not
ification
▶ Developer-facing links:
 Manage Facebook API clients: https://developers.facebook.com/apps
 Using OAuth to access Facebook APIs:
http://developers.facebook.com/docs/reference/api/data-access/
 User info Web API documentation:
• For Web applications as callers:
https://developers.facebook.com/docs/howtos/login/server-side-login/
• For AJAX clients/mobile apps as callers:
https://developers.facebook.com/docs/howtos/login-with-facebook-
using-ios-sdk/
https://developers.facebook.com/docs/getting-started/facebook-sdk-for-
android/3.0/#enablesso
 Cryptographic checksum validation keys: n.a.

Key Observation
Complexity Is Distributed Unevenly
▶ OAuth client complexity: small - in the example:
 Resource exchange: OAuth token sent as URL query parameter
 Token exchange: authorization code sent as form-encoded body
parameter along with client id/secret (client authentication). OAuth token
received in response body (form-factor: JSON)
 Authorization exchange: client id and scopes sent and authorization code
received in URL query parameters
▶ OAuth server complexity: large
 OAuth client run-time:
• Web APIs: OAuth-protection of resource endpoints, OAuth endpoints
• Web UIs: authenticate and authorize, manage granted authorizations
 OAuth client build-time:
• Web APIs resp. UIs: register/manage API clients
 Unlike most other security and IAM protocols, OAuth distributes complexity
unevenly. This is a feature as it helps developers to integrate

Key Observation
Is Client Simplicity a Problem?
▶ No, not all tokens are the same – just as in the real-world:
 Tokens issued by notaries to claim real estate:
▶ Having a variety between low and high-end mechanisms presents a value
▶ IT-security in industry is about managing risks:
 One needs to understand the
• value/exposure of assets
• protection offered by security mechanisms
 One needs to create a sound matching, not:
• Secure mechanism (e.g. notary tokens) for low-value items (baggage)
• Insecure mechanism (e.g. hotel tokens) for high-value items (real estate)
 Tokens issued by hotels to reclaim baggage:

Generalizations – User Authentication
OpenID Connect Overview
▶ OpenID Connect defines a user authentication protocol on top of OAuth 2.0:
 ID token objects: JWT objects that report about authentication events
 UserInfo service: RESTful service to query authenticated information about
the current user; protected by OAuth
▶ The specifications are developed by the OIDF (work-in-progress):
 Basic Client Profile OIDF implementers draft, 2013
 Implicit Client Profile OIDF implementers draft, 2013
 Messages OIDF implementers draft, 2013
 Standard OIDF implementers draft, 2013
 Discovery OIDF implementers draft, 2013
 Dynamic Client Registration OIDF implementers draft, 2013
 Session Management OIDF implementers draft, 2013
▶ The specifications care about simple things:
 How to obtain a token that asserts the authenticated identity of a caller?
 How to use such tokens?
▶ False friend: OpenID Connect is no new flavor of the OpenID 2.0 protocol–it is a
new protocol for user authentication in distributed systems

Server-side transfer of state
The Second Trick: Server-Side SSO
© iC Consult GmbH 2013 - Dr. Oliver Pfaff© iC Consult GmbH 2013 - Dr. Oliver Pfaff
Web
browser
Authorization server
Get with
access_token
200 OK with30x Redirect with
code
User authn
and consent
dialogues
Authorization
endpoint
30x Redirect
with scope
Redirection
endpoint
Token
endpoint
Post with client
creds, code
200 OK with
access_token
Token
client
Identity consumer
Identity provider
Get inputs by tokenGet inputs by code
Bold: objects/endpoints specified by OIDC : exchanges specified by OIDC
,
id_token
UserInfo
(application/json)
OAuth-protected
UserInfo endpoint
UserInfo
client
and
value openid

Abstractions Added by OpenID Connect
▶ OAuth authorization request extensions :
 Parameter values e.g. id_token
 Parameters to instruct on how to conduct user authentication
• With a simple value: e.g. display/prompt
• With a complex value: Request objects
o Based on JWT (draft-ietf-oauth-json-web-token-07.txt)
o Matching samlp:AuthnRequest objects with respect to purpose
▶ OAuth authorization resp. token response extensions:
 Parameters to report about user authentication
• With a complex value: ID token objects
o Based on JWT
o Matching saml:Assertion objects with respect to purpose
▶ UserInfo service:
 RESTful Web service
 Standard claims for UserInfo service responses

Classifying OpenID Connect
▶ OIDC is a user authentication protocol based on OAuth – others that inherit
from OAuth are also feasible. Common recipe:
 Expose a Web API that provides authenticated information about the current
user
 Protect this Web API by means of OAuth
▶ This creates the problem of telling OIDC apart from other OAuth-based user
authentication protocols
▶ A protocol for federated IdM can be called OIDC iff it
 utilizes OAuth 2.0 (RFC 6749) with bearer tokens (RFC 6750) according
the authorization code or implicit grants
 presents the value openid in the OAuth scope parameter of its OAuth
authorization request messages
 presents OIDC ID Token objects in either the OAuth authorization (implicit
grant) or the OAuth token response messages (code grant)

Examples
▶ Login with Facebook: OAuth-based user authentication protocol, not OIDC
 Authorization exchange: no support of the value openid in the OAuth scope
parameter (cf. Permissions for supported scope values)
 Token exchange: conducted via HTTP GET, no JSON response, no ID Token
objects provided
▶ Login with Google: OIDC

Client-sidetransferofstate
Generalizations – App Authentication
The Third Trick: Client-Side SSO
OAuth-protected
resource endpoint
e.g. GMail
Mobile
browser
Resource providerAuthorization server
Authorization
endpoint
Token
endpoint
Mobile device
Mobile
app
200 OK
Feed
(text/xml)
Post/Get/Put/Delete with access_token
User authn
and consent
dialogues
30x Redirects with
scope, code
Some
mechanism to
pass OAuth
creds

Generalizations – App Authentication
Obstacles on the Way…
▶ How to conduct user login/consent dialogues?
 Rely on mobile browser
 Embed WebView component
 Provide own user login/consent UIs in mobile app
▶ Which grants for acquiring OAuth tokens?
 Authorization code, implicit, resource owner password credentials
 Refresh token
 Others
▶ Which OAuth credentials to pass?
 Authorization codes
 Tokens
▶ How to pass OAuth credentials?
 Document titles
 Cookie headers
 Others
▶ Care is needed - a one-size-fits-all solution for authenticating users of mobile
apps and providing SSO experience to them does not yet exist

Generalizations – Grant Types
OAuth Token Acquisition
▶ RFC 6749:
 Authorization code: 3-party token acquisition with authorization codes
based on explicit user authorization for confidential clients (Web applications)
 Implicit: 3-party token acquisition based on explicit user authorization for
public clients (AJAX clients, mobile apps)
 Resource owner password credentials: 2-party token acquisition based on
user credentials without explicit user authorization (for migration purposes)
 Client credentials: 2-party token acquisition based on client credentials
without explicit user authorization
 Refresh token: 2-party token acquisition based on refresh tokens without
explicit user authorization
▶ Bearer profiles (IETF oauth WG drafts):
 JWT/SAML 2 bearer: 2-party token acquisition based on JWT/SAML 2.0
bearer assertions (‘bearer grants’) without explicit user authorization
▶ Proprietary extension grants e.g.:
 Google+ one-time-code: achieves the effects of the authorization code and
implicit grants in a single flow
 Microsoft ACS bearer types: predecessors of JWT/SAML 2 bearer
 …

Generalizations – Kinds of Tokens
Token Zoo
▶ Purposes:
 Authz purposes: access tokens, refresh tokens (RFC 6749) - tokens with
defined purpose but undefined contents – implementations define contents
 Authn purposes: ID tokens (OIDC) - tokens with defined purpose and
contents – claims about authentication event
▶ Types:
 Opaque: tokens with contents that are opaque to token consumers (resource
endpoints) - coupling them to token producers
 Self-contained: tokens with contents that can be processed by token
consumers - decoupling token producers and consumers
▶ Security:
 PoP: tokens that can only be used if accompanied by a PoP e.g. MAC tokens
(draft-ietf-oauth-v2-http-mac-03.txt)
 Bearer (RFC 6750): tokens that any party in possession can use in any way
that other parties in possession can
• False friend: bearer tokens (help to integrate by simplifying clients) vs.
bearer grants (JWT/SAML 2 bearer, provide STS-style exchanges)

Generalizations – IAM Styles
Enterprise vs. Consumer IAM
▶ Main IAM styles:
 EIAM – IAM for enterprise users (you@work):
• Resources and identity records owned by legal entities
• Representatives make decisions for resource pools and groups of users
 CIAM – IAM for consumer users (you@Facebook/Google/Twitter...):
• Resources and identity records owned by individual users
• Individuals make decisions for themselves
▶ Especially authorization is fundamentally different for these IAM styles e.g.
 Different responsibilities
• Administrator-managed vs. user-managed authorization
 Different state engines
• First-policy-then-decision-requests vs. first-decision-requests-then-policy
 OAuth is rooted in the CIAM camp and is somewhat colonialistic:
- 3-party exchanges are CIAM-style - they depend on explicit user consent
- 2-party, STS-style exchanges (e.g. JWT/SAML 2 bearer) shift OAuth
towards EIAM territory

Conclusions
▶ The coincidence of Web APIs and consumer users provides use cases that
change the game for:
 IT-security: new suite of Web security means - OAuth, JOSE…
 IAM: new tricks for user authorization and authentication, SSO in the Web
▶ OAuth and OIDC are already in large-scale production use
 Meanwhile their development is ongoing
▶ IAM key learning: a continental divide exists between EIAM and CIAM
 Mantra: don’t use EIAM hammers for CIAM nails and vice versa
▶ Beware of voodoo discussions:
 Phantom pain: adding bearer tokens to OAuth is bad security-wise - there is
no ‘standard meter’ in IT-security  not true
 Real pain: OAuth extensions e.g. STS-style exchanges, OIDC turn a special-
purpose CIAM tool into a Swiss-knife for many things – {authz, authn},
{user, app authn}, {CIAM, EIAM}  confusion is omnipresent
▶ Keys towards mastership:
 Learn from implementing rather than reading – fuzzy texts around
 Simple things are to be achieved – always keep this in mind

Author
▶ Dr. Oliver Pfaff, oliver.pfaff@ic-consult.com

Abbreviations
ACS Access Control Service
AJAX Asynchronous JavaScript And XML
API Application Programming Interface
Authn Authentication
Authz Authorization
CIAM IAM for Consumer users
DIY Do It Yourself
EIAM IAM for Enterprise users
HTML HyperText Markup Language
HTTP HyperText Transfer Protocol
IAM Identity and Access Management
ID IDentity
IdM Identity Management
IdP Identity Provider
JOSE JavaScript Object Signing and
Encryption
JSON JavaScript Object Notation
JWT JSON Web Token
OAuth Open Authorization
OIDC OpenID Connect
OIDF OpenID Foundation
PoP Proof-of-Possession
REST REpresentational State Transfer
SAML Security Assertion Markup Language
saml: SAML assertion syntax namespace prefix
samlp: SAML protocol syntax namespace prefix
SSO Single-Sign-On
STS Security Token Service
UI User Interface
XML eXtensible Markup Language

Further Information
▶ Bertocci, Vittorio: OAuth 2.0 and Sign-In. Blog 2013
▶ Bray, Tim: Verifying Back-End Calls from Android Apps. Blog 2013
▶ Bray, Tim: On ID Tokens. Blog 2013
▶ Class, Gus: Using the one-time-code flow with Google+ Sign-in. Blog 2013
▶ Jones, Mike: The Emerging JSON-Based Identity Protocol Suite. Paper - W3C
Workshop on Identity in the Browser 2011
▶ Jones, Mike: OpenID Connect Update. Presentation - OpenID Workshop,
European Identity Conference 2013
▶ Kiani, Khash: OAuth-Securing the Insecure. Presentation 2011
▶ Madsen, Paul: Mobile Native App-OAuth Decision Framework. Presentation 2011
▶ N.N.: OAuth 2 for Native Apps. Wiki 2011
▶ Richer, Justin: Auth* in the Extended Enterprise. Presentation - MIT Legal Hack-
A-Thon 2013
▶ Yegge, Steve: Stevey's Google Platforms Rant. Posting 2011

OAuth Base Camp

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a OAuth Base Camp

Similar a OAuth Base Camp (20)

Más de Oliver Pfaff

Más de Oliver Pfaff (15)

Último

Último (20)

OAuth Base Camp