Contenu connexe
Similaire à OAuth 101 & Secure APIs 2012 Cloud Identity Summit (20)
Plus de Brian Campbell (16)
OAuth 101 & Secure APIs 2012 Cloud Identity Summit
- 1. OAuth 101 & Secure API's
It's all ball bearings (APIs) nowadays
An authentication and
authorization framework for
the future of the Interwebs
Brian Campbell
1 @weeUnquietMind
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 2. Agenda
• Introduction
• OAuth drivers
• Screenshot demo
• OAuth history
• OAuth 2
• OAuth in context
• OAuth security model
2 Copyright ©2012 Ping Identity Corporation. All rights reserved.
2
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 3. Who the heck is this guy anyway?
@weeUnquietMind – the short story of an unfortunate handle
As Senior Architect for Ping Identity, Brian Campbell aspires to one day
know what a Senior Architect actually does for a living. In the meantime,
he tries to make himself useful by ideating, designing and building
software systems such as Ping‟s flagship product PingFederate. When not
making himself useful, he contributes to various identity and security
standards including a two-year stint as co-chair of the OASIS Security
Services Technical Committee and a current focus on OAuth 2.0 and
JOSE within the IETF as well as OpenID Connect. He holds a B.A.,
magna cum laude, in Computer Science from Amherst College in
Massachusetts. Despite spending four years in the state, he has to look up
how to spell "Massachusetts" every time he writes it.
3 Copyright ©2012 Ping Identity Corporation. All rights reserved.
3
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 4. Draft -28 of The OAuth 2.0 Authorization Framework
4
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 5. Draft -28 of The OAuth 2.0 Authorization Framework
5 Page 70
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 6. Draft -28 of The OAuth 2.0 Authorization Framework
Prominently mentioned
in the second to last
paragraph of the very
last page.
6 Page 70
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 7. Better Placement on Some Lesser Known Specs
7 Copyright ©2012 Ping Identity Corporation. All rights reserved.
7
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 8. Some Might Even Call Them Esoteric…
8 Copyright ©2012 Ping Identity Corporation. All rights reserved.
8
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 9. Agenda
• Introduction
• OAuth drivers
• Screenshot demo
• OAuth history
• OAuth 2
• OAuth in context
• OAuth security model
9 Copyright ©2012 Ping Identity Corporation. All rights reserved.
9
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 10. Drivers
10 Copyright ©2012 Ping Identity Corporation. All rights reserved.
10
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 11. In the Beginning there was SOAP…
Simple [sic] Object Access Protocol
… and SOAP based SOA was going to change the world
11 Copyright ©2012 Ping Identity Corporation. All rights reserved.
11
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 12. SOAP was given Authentication
• The SOAP world has long had standards related
to authentication & authorization of web services
• WS-Trust defines a protocol by which a SOAP
client can obtain a security token (typically a
SAML assertion)
• WS-Security stipulates how to attach the token
(SAML assertion) to a SOAP request
• WS-* does a few other things too
12 Copyright ©2012 Ping Identity Corporation. All rights reserved.
12
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 13. However…
Apparently people are lazy and really like to REST…
13
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 14. But just for some perspective…
14
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 15. 1) REST authentication
• (The) REST (of the) world has not had
comparable standards
• Nothing comparable to WS-Security - mishmash
of HTTP Basic, HTTP Digest, proprietary
mechanisms, and mutual SSL for client
authentication
• Nothing comparable to WS-Trust
– consequently client bears burden of managing
credentials & trust
15
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 16. 2) Password anti-pattern
Other sites asks
YOU for your
GOOGLE password
so it can access
your Google stuff.
16
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 17. Tsk tsk!
• Requesting sites and apps store the
passwords
• Hosting sites get locked into password
authentication
• Teaches users to be (more) indiscriminate with
their passwords
• Doesn‟t support granular permissions
• Hosting site is not involved in, and has no
knowledge of, the authorization step
• Changing password (good security hygiene)
revokes access to all
• No easy way to revoke access
17
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 19. 3) Cloud! CLOUD! CLOUD! CLOUD! CLOUD! APIs
Cloud Cures Everything!
19 Copyright ©2012 Ping Identity Corporation. All rights reserved.
19
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 20. 3) Cloud APIs
• Within move towards SaaS – trend towards API
access to data/services to supplement, or even
replace, browser access
• Salesforce.com: over 60% of access is via API
• APIs of PaaS offerings allow the customer to
expose its own cloud services
• Clear trend for these APIs is towards REST
20 Copyright ©2012 Ping Identity Corporation. All rights reserved.
20
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 21. 4) The Rise of Native Mobile Apps
• Typically interact
with internet APIs
• Require
authentication &
authorization
21
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 22. Aside: Mobile Application Continuum
Web Applications Native Applications
Hybrid
Web Server
Web Server
Web App
HTML/JS/CSS Hybrid Approaches JSON/XML
Mobile Device Mobile Device
Mobile Web
Page Native App
Browser
22 Copyright ©2012 Ping Identity Corporation. All rights reserved.
22
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 23. Aside - Native / Hybrid / Web
• Not going to try to predict winner
• Expect them all
• Hybrid gaining momentum
• Authentication & authorization should be consistent
across both models, so that,
• Users are not confused, e.g. use different
credentials and/or authentication ceremony for the
two models, even if accessing the same application
• Service providers aren‟t forced to implement
multiple security frameworks for the two models
23
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 24. Drivers
Password
Lack of anti-
standards pattern
Cloud
Native
APIs
mobile
Applications
24
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 25. Enter OAuth!
• An open protocol to allow secure API
authorization in a simple and standard method
from desktop, mobile and web applications.
• Defines an authorization & authentication
framework for RESTful APIs (and more)
• Mitigates password anti-pattern
– In archetypical use case of delegated authorization
• Provides a standard way to give a „key‟ to a third-
party which allows only limited access to perform
specific functions
– Without divulging your credentials
25
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 26. An Overused Analogy
OAuth is your valet key to the Interwebs
It‟s going happen one way or the other so may
as well tax and regulate…
26 Copyright ©2012 Ping Identity Corporation. All rights reserved.
26
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 27. Agenda
• Introduction
• OAuth drivers
• Screenshot demo
• OAuth history
• OAuth 2
• OAuth in context
• OAuth security model
27 Copyright ©2012 Ping Identity Corporation. All rights reserved.
27
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 28. Screenshot Demo: brizzly.com accesses the twitters
API @
brizzly.com
Twitter
Web Interface
28
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 30. Screenshot Demo: (now defunct) brizzly.com accesses the twitters
30
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 31. Screenshot Demo: (now defunct) brizzly.com accesses the twitters
31
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 32. Screenshot Demo: (now defunct) brizzly.com accesses the twitters
32
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 33. Screenshot Demo: (now defunct) brizzly.com accesses the twitters
33
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 34. Screenshot Demo: (now defunct) brizzly.com accesses the twitters
34
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 35. Screenshot Demo: (now defunct) brizzly.com accesses the twitters
35
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 36. Screenshot Demo: (now defunct) brizzly.com accesses the twitters
36
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 37. Screenshot Demo: (now defunct) brizzly.com accesses the twitters
37
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 38. Agenda
• Introduction
• OAuth drivers
• Screenshot demo
• OAuth history
• OAuth 2
• OAuth in context
• OAuth security model
38 Copyright ©2012 Ping Identity Corporation. All rights reserved.
38
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 39. A [confusing] Little History
• First was the Emergence of Proprietary Solutions
– Google AuthSub, AOL OpenAuth, Yahoo
BBAuth, Upcoming API, Flickr API, AWS API, and more
• OAuth Core 1.0 [Oct 2007]
– Open protocol to standardize what was already being
done
• OAuth Core 1.0 Revision A [June 2009]
– Addresses a session fixation attack
• The OAuth 1.0 Protocol / RFC 5849 [April 2010]
– Move to the IETF as informational documentation of
1.0a with editorial clarifications and errata
39
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 40. More History, Still Confusing
• OAuth WRAP (Web Resource Authorization
Profiles) [Jan 2010]
– Better Support for non-web applications
– Simplify the Client
– Short lived, opaque, bearer access tokens with
long lived refresh tokens
– Cleaner separation of roles
• Server handling authorization requests
• Server handling protected resource access
• Client
– Simple Web Token (SWT)
• Attempt to standardize an access token format
• Oauth 2.0 [in progress]
– *still* in progress
40
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 41. Agenda
• Introduction
• OAuth drivers
• Screenshot demo
• OAuth history
• OAuth 2
• OAuth in context
• OAuth security model
41 Copyright ©2012 Ping Identity Corporation. All rights reserved.
41
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 42. OAuth 2.0
• 2 is better than 1
• Conceptually similar to WRAP
• With built in extensibility
• Clear separation of getting a token and using a token
– Early drafts had an option for token signatures but that was dropped
– "OAuth 2.0 is Bad for the Web” – spec author/editor
– Bearer tokens (separate spec)
– Return of the MAC
– MAC, we hardly knew ye
• Approaching final standardization in IETF
– Sigh
– I‟ve been writing that in presentations dating back to December of 2010
– Currently at draft -30 (as of last night)
• Applicable to many other scenarios – even those with no users
• Notable for its optimizations for mobile
– Kind of…
42
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 43. OAuth 2.0 Terminology: Roles
• resource owner: an entity
(usually an end-
user/person)capable of
granting access to a protected
resource .
• client: an application
obtaining authorization and
making protected resource
requests (on behalf of the
resource owner).
• resource server (RS): the
server hosting protected
resources
• authorization server (AS): a
server capable of issuing
tokens, obtaining
authorization, and
authenticating resource
owners.
43
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 44. More Terminology: Tokens
• Access Token
– credential used by client to access protected resources at
the RS
– permissions afforded by the token can be scoped
– issued by the AS
– structure is undefined by the spec(s)
– usually opaque to the client
– generally short lived
– can be self contained or a reference
– shifts complexity from the RS to the AS
• Refresh Token
– used by client to obtain a new access token when the old
one expires
– client only sends to AS, never to RS
– generally long lived
44
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 45. Access Token Types
• Access tokens can have different
– formats
– structures
– methods of utilization (e.g. cryptographic properties)
• Access tokens must be defined by companion
specifications
– token_type
– additional parameters as needed
– how to use at RS
45
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 46. Bearer Access Tokens
• Any party in possession of the token (a
"bearer") can use the token in any way that
any other party in possession of it can.
• token_type: Bearer
• Token can be presented to the RS in HTTP
Authorization Header, Body Parameter, or
Query Parameter
• Requires TLS
• Token structure still undefined
46
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 47. MAC Access Tokens
• A.k.a. Proof of possession token, proof token, HoK token
• Defines an HTTP MAC access authentication scheme
(key id, MAC key & algorithm, and issue time)
– Id is sent with request
– Key is shared symmetric secret between the client and the
server used to „sign‟ requests (thereby proving possession of
the secret)
• OAuth 2.0 binding for use as an access-token type
– token_type: mac
– Key id is the access_token
• Format & structure is still undefined
– mac_key & mac_algorithm as additional parameters
• Protects against token leakage
• Kinda still needs TLS in some cases
• Future uncertain…
47
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 48. More Terminology: Endpoints
• AS Endpoints
– Authorization endpoint
• used, via user-agent redirection, to authenticate and obtain
authorization from the resource owner.
• End user on the front channel.
– Token endpoint
• Used to exchange an authorization grant for an access token.
• Client on the back channel.
• Client Endpoint
– Redirection URI
• After completing its interaction with the resource owner, the AS
directs the resource owner's user-agent back to the client at the
client‟s redirection URI.
• Front channel callback
48
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 49. Terminology: Authorization Grant
• General term used to describe the intermediate
credentials representing the resource owner
authorization
• Serves as an abstraction layer
– not the cleanest abstraction
• Used by the client to obtain an access token
• All token endpoint calls involve exchanging some
grant for an access token
• Spec defines several types as well as an
extensibility mechanism
49
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 50. Terminology: Scope
• The definition of scope is (mostly) out of scope
– See what I did there?
– The scope of the access request is expressed as a list of
space-delimited, case sensitive strings.
– Order doesn‟t matter.
– The value and meaning of scope strings are defined by the
authorization server.
• Requesting/granting specific scope(s) allows the
access rights associated with a token to be limited
– Enables the principle of least privilege (or less privilege
anyway)
– Only ask for what is needed
50
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 51. Some Scope Examples
• Facebook
– publish_stream
– publish_checkins
– read_mailbox
– email
– user_status
• Google
– https://www.googleapis.com/auth/adsense
– https://www.googleapis.com/auth/plus.me
– https://www.googleapis.com/auth/urlshortener
– https://mail.google.com/mail/feed/atom
– https://www.googleapis.com/auth/plus.me
• OpenID Connect
– openid
– email
– profile
– phone
– address
51
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 52. Abstract Flow
• Client obtains authorization grant from resource
owner*
• Client calls the authorization server to exchange
the grant for an access token**
• Client uses the access token to access protected
resources at the resource server***
*sometimes
**usually
***probably
52
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 53. Authorization Grant Types
• authorization code
• implicit*
• resource owner password credentials
• client credentials
• refresh token
• Extensions
* one of these things is not like the others…
53
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 54. Grant Type: Authorization Code
• Client sends resource owner, via browser, to the
authorization endpoint at the AS
– End-user authenticates
– End-user approves requested access
• AS sends the end-user to the client‟s redirect URI
and includes the authorization code as a query
parameter
• Client receives the redirection callback, extracts the
code, and sends it to the AS in exchange for an
access token (and probably a refresh token)
• Great for web app clients
– Client authentication
– Easy to handle the redirect
• Okay for mobile clients
– Without client authentication
– Need tricks to handle the redirect/callback
54
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 55. Getting an Authorization Code
Authorization Request
GET /as/authorization.oauth2?client_id=aclient&
redirect_uri=https%3A//client.example.com/cb&
response_type=code&scope=beer+hockey+donuts HTTP/1.1
Host: server.example.com
[…This is where the magic happens…]
Authorization Response
HTTP/1.1 302 Found
Location:
https://client.example.com/cb?code=GecMEdixSKRJO8xfpCXHg9Fg2
Hze
55
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 56. Exchange Authorization Code for Access Token
Access Token Request
POST /as/token.oauth2 HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
client_id=aclient&client_secret=hoser&redirect_uri=https%3A//client.example.com/cb&grant_ty
pe=authorization_code&code=GecMEdixSKRJO8xfpCXHg9Fg2Hze
Access Token Response
HTTP/1.1 200 OK
Cache-Control: no-store
Pragma: no-cache
Content-Type: application/json;charset=UTF-8
{
"token_type":"Bearer",
"access_token":"a0VuzD3NfDsjCsTUZB5LmXs7WPQ1x07DCHR”,
"expires_in":3600,
"refresh_token":"mSTBpqQcSkRECNfDclfRDjREnmqeWVap0DseM6aXkixIX”
}
56
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 57. Brief Interlude: Using the Access Token
Protected Resource Request with a Bearer Token
GET /double/secret/probation/resource HTTP/1.1
Host: rs.example.com
Authorization: Bearer a0VuzD3NfDsjCsTUZB5LmXs7WPQ1x07DCHR
MAC Token a Bit More Complicated
POST /take/off/eh HTTP/1.1
Host: rs.example.com
Content-Type: application/x-www-form-urlencoded
Authorization: MAC id="jd93dh9dh39D",
nonce="273156:di3hvdf8",
bodyhash="k9kbtCIy0CkI3/FEfpS/oIDjk6k=",
mac="W7bdMZbv9UWOTadASIQHagZyirA="
57
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 58. Grant Type: Implicit
• Similar to the authorization code flow except…
• After resource owner authentication and
authorization, the AS sends the end-user to the
client‟s redirect URI and includes the access
token on the fragment (#)
• No token endpoint call so not *really* a grant
type
• Optimized for „widget‟ clients or in-browser
JavaScript applications
• Could also work for native/mobile clients
58
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 59. Getting a Token with Implicit
Authorization Request
GET /as/authorization.oauth2?client_id=aclient&
redirect_uri=https%3A//client.example.com/cb&response_type=token HTTP/1.1
Host: server.example.com
[…magic happens…]
Authorization Response
HTTP/1.1 302 Found
Location: https://client.example.com/cb#expires_in=3600
&token_type=Bearer&access_token=gBjAAf7Io0FIfwZaXDTRQg0d7GTwAOL7G6e
Protected Resource Request
GET /double/secret/probation/resource HTTP/1.1
Host: rs.example.com
Authorization: Bearer gBjAAf7Io0FIfwZaXDTRQg0d7GTwAOL7G6e
59
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 60. Grant Type: Resource Owner Password Credentials
• Client obtains resource owner‟s username
and password directly from the resource
owner and sends them directly to the AS as a
grant.
• Requires trust in the client.
• Refresh token eliminates the need for the
client to store the password.
• Somewhat intended as a migration
mechanism
60
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 61. Exchange Resource Owner Password Credentials for Access Token
Access Token Request
POST /as/token.oauth2 HTTP/1.1
Host: as.example.com
Authorization: Basic c29tZWNsaWVudDpBbWVyaWNhJ3NIYXQ=
Content-Type: application/x-www-form-urlencoded
grant_type=password&username=pmadsen&password=uselesstaxonomy
Access Token Response
HTTP/1.1 200 OK
Cache-Control: no-store
Pragma: no-cache
Content-Type: application/json; charset=UTF-8
{
"token_type":"Bearer",
"access_token":"a0VuzD3NfDsjCsTUZB5LmXs7WPQ1x07DCHR”,
"expires_in":3600,
"refresh_token":"mSTBpqQcSkRECNfDclfRDjREnmqeWVap0DseM6aXkixIX”
}
61
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 62. Grant Type: Client Credentials
• Client can request an access token using only its
own credentials
• For resources under the client‟s control or other
resources as policy dictates
• MUST only be used by “private” clients (clients that can
authenticate securely)
• No refresh token
• Client Authentication Mechanisms
– client_id & client_secret parameters
– HTTP Basic
– “The authorization server MAY support any suitable HTTP
authentication scheme matching its security requirements”
– Mutual TLS
– client_assertion & client_assertion_type parameters
62
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 63. Grant Type: Refresh Token
• If a refresh token was issued to the client
during the exchange of a prior grant, it can be
used as an authorization grant to get a new
access token
– Unless revoked or otherwise invalid
• Refresh an expired access token without
involving direct user authorization
• The AS may issue a new refresh token
– Good security hygiene
63
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 64. Refreshing an Access Token
Access Token Request
POST /as/token.oauth2 HTTP/1.1
Host: as.example.com
Authorization: Basic c29tZWNsaWVudDpBbWVyaWNhJ3NIYXQ=
Content-Type: application/x-www-form-urlencoded
grant_type=refresh_token&refresh_token=1StDpqQcSk1CNf7clfRjREnmqeiVap0DseM6aXkixI11
Access Token Response
HTTP/1.1 200 OK
Cache-Control: no-store
Pragma: no-cache
Content-Type: application/json; charset=UTF-8
{
"token_type":"Bearer",
"access_token":"MdqBuexXYlMSogbrAwiPP47eGxGqZajuJNa”,
"expires_in":3600,
"refresh_token":"hlyEOO9PXgmvPiYI8g68KSEs2HQhgrkiUQGsc9Xxskd”
}
64
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 65. Extension Grant Types
• Extension authorization grant types can be
defined by assigning them a unique absolute URI
for use with the "grant_type" parameter.
• Extensions can define additional parameters
needed.
• Enables bridging between OAuth and other
protocols.
– SAML 2.0
– JWT 1.0
• (kind of) Enables other stuff too
– Bearer access token validation
– STS style token exchange
65
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 66. Partial Specification Landscape
Getting a Token Using a Token
The OAuth 2.0 Authorization Framework The OAuth 2.0 Protocol: Bearer Tokens
draft-ietf-oauth-v2 draft-ietf-oauth-v2-bearer
HTTP Authentication: MAC Access Authentication
draft-ietf-oauth-v2-http-mac
Extension Grants
& OAuth 2.0 Assertion Profile
Client Authentication draft-ietf-oauth-assertions
Tokens Assertions and Protocols for SAML V2.0
saml-core-2.0-os
XML Sec
SAML 2.0 Bearer Assertion Grant
JSON Web Token (JWT)
Type Profile for OAuth 2.0
draft-ietf-oauth-json-web-token
draft-ietf-oauth-saml2-bearer
JSON Web Token (JWT) Bearer
JSON Web Signature (JWS)
Profile for OAuth 2.0
draft-ietf-jose-json-web-signature
draft-ietf-oauth-jwt-bearer
JSON Web Signature (JWE)
draft-ietf-jose-json-web-encryption
JSON Web Key (JWK)
Other Protocols JOSE draft-ietf-jose-json-web-key
User-Managed Access (UMA) JSON Web Key (JWA)
Core Protocol
OpenID Connect 1.0 draft-ietf-jose-json-web-algorithms
draft-hardjono-oauth-umacore
66
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 67. Agenda
• Introduction
• OAuth drivers
• Screenshot demo
• OAuth history
• OAuth 2
• OAuth in context
• OAuth security model
67 Copyright ©2012 Ping Identity Corporation. All rights reserved.
67
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 68. OAuth in Context
Compare, Contrast & Compose
68
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 69. OAuth relationship to OpenID
• They are different
– Authorization vs. Authentication
• They share similarities
– Web redirect flows
• Client to AS
• RP to OP
– End user authentication
• To AS
• To OP
• Lines between roles and goals of each often blur
– An OP is also an AS who has RSs that the Client/RP wants
to access
– An AS can be an RS and defer to an OP for user
authentication
• Similarities and overlap have, in part, motivated the
building the next version of OpenID „on top of‟ OAuth
69
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 70. OpenID Connect
• Adds a thin 'identity layer' onto OAuth 2.0
• Designed to address limitations of OpenID
2.0 (URL length issues, LOA ceiling,
implementation complexity, etc.)
• Reflects a harmonization of multiple
competing visions for evolution of OpenID 2.0
• Designed to allow for support of higher LOA
70
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 71. OpenID Connect Family tree
Artifact
Hybrid
Extension
OAuth 1
OAuth 2 JWT
71
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 72. 72
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 73. OpenID Connect relation to OAuth
• Whereas OAuth is a general mechanism to
authorize API access, OpenID Connect profiles
the generic for purposes of sharing profile
information
• OpenID Connect adds a security token explicitly
for SSO from AS to Client
• Uses the authorization code & implicit grant
types – the pieces of OAuth optimized for user-
consent scenarios
• Leverages the authorization & token endpoints &
adds identity-based params to core OAuth
messages
73
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 74. SAML & OAuth
SAML 'Hybrid' – carry OAuth token
OAuth
in SAML SSO messages
SAML assertions sent within
OAuth OAuth messages
SAML
SAML OAuth 'Sequencing' – use SAML SSO
to authenticate user to AS
74
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 75. Sequencing SAML & OAuth
OAuth
SAML
OAuth
75
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 76. Trading Tokens
SAML JWT Profiles for specific
assertion
Formats [2] & [3]
Assertion profile How to use assertions
as a grant type [1] (also
client authentication)
OAuth Core protocol [0]
[0] - http://tools.ietf.org/html/draft-ietf-oauth-v2
[1] - http://tools.ietf.org/html/draft-ietf-oauth-assertions
[2] - http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer
76 [3] - http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 77. Using a SAML Assertion (or JWT) as an OAuth grant type
SAML
POST /token.oauth2 HTTP/1.1
Host: authz.example.net
Content-Type: application/x-www-form-urlencoded
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Asaml2-bearer
&assertion=PEFzc2VydGlvbiBJc3N1ZUluc3Rh [...omitted for brevity...]lbnQ-PC9Bc3NlcnRpb24-
JWT
POST /token.oauth2 HTTP/1.1
Host: authz.example.net
Content-Type: application/x-www-form-urlencoded
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer
&assertion=eyJhbGciOiJFUzI1NiJ9.eyJpc3Mi[...omitted for brevity...].J9lZhwP_2n[...omitted...]
77
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 78. OAuth relationship to XACML
• eXtensible Access Control Markup Language
– A declarative access control policy language in XML and a
processing model describing how to evaluate authorization
requests according to the rules defined in policies.
– PAP
• Administration
– PDP
• Decision
– PEP
• Enforcement
Though both focused on
authorization, OAuth & XACML are
very different animals
78
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 79. OAuth is Authorization?
• Depends on what part of
the authz elephant you
are looking at
– Policy (XACML)
– Query (XACML/SAML
profile)
– Claims (SAML & JWT)
– User consent (OAuth)
– Permissions (OAuth)
But if your use cases don’t
involve user-consent,
then OAuth starts to
look more like
authentication (be careful)
79
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 80. UMA & OAuth
• User Managed Access extends OAuth 2.0 to allow for a user to
manage access to multiple (and distributed) resources through
centralized Authorization Manager
• UMA “provides a method for users to control access to their protected
resources, residing on any number of host sites, through an
authorization manager that governs access decisions based on user
policy.”
• Leverages separation between AS & RS introduced with WRAP & v2
• Defines how a host can ask the authorization manager to validate
tokens in real
• Supports more dynamic registration
80
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 81. Agenda
• Introduction
• OAuth drivers
• Screenshot demo
• OAuth history
• OAuth 2
• OAuth in context
• OAuth security model
81 Copyright ©2012 Ping Identity Corporation. All rights reserved.
81
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 82. OAuth 2 Security Model
• Well, it sort of depends…
– Token type
– Grant type
– Client type
• Also, it‟s kind of complicated…
• Threat model doc is as long as the core spec
– http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel
(currently at -06)
• So just going to look at some aspects of it
here
82
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 83. Session Cookie Analogy
• OAuth using bearer tokens is sort of like session
cookies for API/resource access
• Generally you login to a website and are issued a
session cookie for subsequent requests
• Grant is like the login while the access token is
like the session cookie
• TLS is required at every step
• Cookies rely on same origin policy
• Access tokens rely on static or well know servers
• Neither is perfect
• Discovery cannot be safely done with bearer
tokens
83
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 84. What about MAC?
• Helps with the discovery problem
• Still kind of similar to session cookies
– In fact, the MAC spec once defined an extension to the
HTTP "Set-Cookie " response header field
– Didn‟t last
• Does prevents credential leakage
• Can be used over insecure channels
– Adds complexity (normalization, cryptography, state
management)
– No confidentiality (still need TLS for that)
• Spec‟s future is unclear…
– Return of the MAC part II?
– Others (last week, for example, draft-tschofenig-oauth-
hotk-00)?
84
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 85. Tokens & Signing
• Signed Tokens
– Token is signed by the issuer (AS)
– JWT, SWT, SAML, etc.
– Token is self-contained
• Signing with Tokens
– Client signs the request with some secret issued
along side the token
– MAC
– Token can be self-contained or reference
85
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 86. But Why aren‟t Tokens Defined?
• It‟s okay, it really is
• I don‟t know why exactly, but I‟ve grown to
accept and even like it
• It does imply some level of coordination
between the AS & RS
• Time will tell…
86
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 87. Not for Single Sign-On
• OAuth (alone) is not for cross domain SSO
– Primarily about protecting the protected resource
• That‟s why it‟s called that
• While also enabling delegated access
– But not the client
• (Under certain circumstances) a token or code can
be swapped and used to gain full access to a
different client
– Client relying on OAuth to authenticate to resources other
than the RS for which the access token is issued
– Implicit & unauthenticated code flows
• A user grants a client access to info/resources at an
RS but not to access resources a different
client/website
– Client has not Authenticated the user but rather only gotten
delegated access to the users information.
• A good discussion of the issue by my colleague John
Bradley
– http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html
87
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 88. Other Security Stuff
• Reference style tokens need sufficient entropy
• Revocation is good to provide
• TLS
• Client authentication and binding clients to
grants/codes/tokens
– Identification alone is also useful
• Brute force countermeasures
• Token storage
• Token/code leakage
• Phishing
• Did I mention TLS?
• Scope of scopes
88
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
- 89. Thanks! (and time permitting)
Questions?
(there are no stupid questions, only stupid answers and I‟m
tremendously qualified to deliver such answers)
OAuth 101 & Secure API's
It's all ball bearings (APIs) nowadays Brian Campbell
89 @weeUnquietMind
Copyright © 2012. Cloud Identity Summit. All Rights Reserved.