OAuth 101 & Secure APIs 2012 Cloud Identity Summit
Upcoming SlideShare
Loading in...5
×
 

OAuth 101 & Secure APIs 2012 Cloud Identity Summit

on

  • 4,692 views

OAuth 101 & Secure API's

OAuth 101 & Secure API's

It's all ball bearings (APIs) nowadays

An authentication and authorization framework for the future of the Interwebs

Statistics

Views

Total Views
4,692
Views on SlideShare
4,640
Embed Views
52

Actions

Likes
5
Downloads
123
Comments
0

3 Embeds 52

https://si0.twimg.com 25
http://tspace.web.att.com 23
https://twitter.com 4

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

OAuth 101 & Secure APIs 2012 Cloud Identity Summit OAuth 101 & Secure APIs 2012 Cloud Identity Summit Presentation Transcript

  • OAuth 101 & Secure APIs Its all ball bearings (APIs) nowadays An authentication andauthorization framework forthe future of the Interwebs Brian Campbell1 @weeUnquietMind Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • Agenda • Introduction • OAuth drivers • Screenshot demo • OAuth history • OAuth 2 • OAuth in context • OAuth security model2 Copyright ©2012 Ping Identity Corporation. All rights reserved.2 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • 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. View slide
  • Draft -28 of The OAuth 2.0 Authorization Framework4 Copyright © 2012. Cloud Identity Summit. All Rights Reserved. View slide
  • Draft -28 of The OAuth 2.0 Authorization Framework5 Page 70 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • 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.
  • Better Placement on Some Lesser Known Specs7 Copyright ©2012 Ping Identity Corporation. All rights reserved.7 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • Some Might Even Call Them Esoteric…8 Copyright ©2012 Ping Identity Corporation. All rights reserved.8 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • Agenda • Introduction • OAuth drivers • Screenshot demo • OAuth history • OAuth 2 • OAuth in context • OAuth security model9 Copyright ©2012 Ping Identity Corporation. All rights reserved.9 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • Drivers10 Copyright ©2012 Ping Identity Corporation. All rights reserved.10 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • In the Beginning there was SOAP… Simple [sic] Object Access Protocol … and SOAP based SOA was going to change the world11 Copyright ©2012 Ping Identity Corporation. All rights reserved.11 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • 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 too12 Copyright ©2012 Ping Identity Corporation. All rights reserved.12 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • However… Apparently people are lazy and really like to REST…13 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • But just for some perspective…14 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • 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 & trust15 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • 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.
  • 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 access17 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • Importance of revocation18 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • 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.
  • 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 REST20 Copyright ©2012 Ping Identity Corporation. All rights reserved.20 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • 4) The Rise of Native Mobile Apps • Typically interact with internet APIs • Require authentication & authorization21 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • 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 Browser22 Copyright ©2012 Ping Identity Corporation. All rights reserved.22 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • 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 models23 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • Drivers Password Lack of anti- standards pattern Cloud Native APIs mobile Applications24 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • 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 credentials25 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • 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.
  • Agenda • Introduction • OAuth drivers • Screenshot demo • OAuth history • OAuth 2 • OAuth in context • OAuth security model27 Copyright ©2012 Ping Identity Corporation. All rights reserved.27 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • Screenshot Demo: brizzly.com accesses the twitters API @ brizzly.com Twitter Web Interface28 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • About Brizzly… Remember Revocation?29 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • Screenshot Demo: (now defunct) brizzly.com accesses the twitters30 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • Screenshot Demo: (now defunct) brizzly.com accesses the twitters31 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • Screenshot Demo: (now defunct) brizzly.com accesses the twitters32 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • Screenshot Demo: (now defunct) brizzly.com accesses the twitters33 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • Screenshot Demo: (now defunct) brizzly.com accesses the twitters34 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • Screenshot Demo: (now defunct) brizzly.com accesses the twitters35 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • Screenshot Demo: (now defunct) brizzly.com accesses the twitters36 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • Screenshot Demo: (now defunct) brizzly.com accesses the twitters37 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • Agenda • Introduction • OAuth drivers • Screenshot demo • OAuth history • OAuth 2 • OAuth in context • OAuth security model38 Copyright ©2012 Ping Identity Corporation. All rights reserved.38 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • 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 errata39 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • 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 progress40 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • Agenda • Introduction • OAuth drivers • Screenshot demo • OAuth history • OAuth 2 • OAuth in context • OAuth security model41 Copyright ©2012 Ping Identity Corporation. All rights reserved.41 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • 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.
  • 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.
  • 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 lived44 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • 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 RS45 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • 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 undefined46 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • 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.
  • 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 owners user-agent back to the client at the client‟s redirection URI. • Front channel callback48 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • 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 mechanism49 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • 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 needed50 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • 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 – address51 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • 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 ***probably52 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • 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.
  • 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/callback54 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • Getting an Authorization Code Authorization RequestGET /as/authorization.oauth2?client_id=aclient& redirect_uri=https%3A//client.example.com/cb& response_type=code&scope=beer+hockey+donuts HTTP/1.1Host: 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.
  • Exchange Authorization Code for Access Token Access Token RequestPOST /as/token.oauth2 HTTP/1.1Host: as.example.comContent-Type: application/x-www-form-urlencodedclient_id=aclient&client_secret=hoser&redirect_uri=https%3A//client.example.com/cb&grant_type=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.
  • Brief Interlude: Using the Access TokenProtected Resource Request with a Bearer TokenGET /double/secret/probation/resource HTTP/1.1Host: rs.example.comAuthorization: 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.
  • 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 clients58 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • Getting a Token with Implicit Authorization RequestGET /as/authorization.oauth2?client_id=aclient& redirect_uri=https%3A//client.example.com/cb&response_type=token HTTP/1.1Host: 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 RequestGET /double/secret/probation/resource HTTP/1.1Host: rs.example.comAuthorization: Bearer gBjAAf7Io0FIfwZaXDTRQg0d7GTwAOL7G6e 59 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • 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 mechanism60 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • Exchange Resource Owner Password Credentials for Access Token Access Token RequestPOST /as/token.oauth2 HTTP/1.1Host: as.example.comAuthorization: Basic c29tZWNsaWVudDpBbWVyaWNhJ3NIYXQ=Content-Type: application/x-www-form-urlencodedgrant_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.
  • 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 parameters62 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • 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 hygiene63 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • Refreshing an Access Token Access Token RequestPOST /as/token.oauth2 HTTP/1.1Host: as.example.comAuthorization: Basic c29tZWNsaWVudDpBbWVyaWNhJ3NIYXQ=Content-Type: application/x-www-form-urlencodedgrant_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.
  • 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 exchange65 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • Partial Specification LandscapeGetting 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-keyUser-Managed Access (UMA) JSON Web Key (JWA) Core Protocol OpenID Connect 1.0 draft-ietf-jose-json-web-algorithmsdraft-hardjono-oauth-umacore66 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • Agenda • Introduction • OAuth drivers • Screenshot demo • OAuth history • OAuth 2 • OAuth in context • OAuth security model67 Copyright ©2012 Ping Identity Corporation. All rights reserved.67 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • OAuth in Context Compare, Contrast & Compose68 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • 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‟ OAuth69 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • 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 LOA70 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • OpenID Connect Family tree Artifact Hybrid ExtensionOAuth 1 OAuth 2 JWT71 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • 72 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • 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 messages73 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • 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 AS74 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • Sequencing SAML & OAuth OAuth SAML OAuth75 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • 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-bearer76 [3] - http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • Using a SAML Assertion (or JWT) as an OAuth grant typeSAMLPOST /token.oauth2 HTTP/1.1Host: authz.example.netContent-Type: application/x-www-form-urlencodedgrant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Asaml2-bearer&assertion=PEFzc2VydGlvbiBJc3N1ZUluc3Rh [...omitted for brevity...]lbnQ-PC9Bc3NlcnRpb24-JWTPOST /token.oauth2 HTTP/1.1Host: authz.example.netContent-Type: application/x-www-form-urlencodedgrant_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.
  • 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 • EnforcementThough both focused onauthorization, OAuth & XACML arevery different animals78 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • 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.
  • 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.
  • Agenda • Introduction • OAuth drivers • Screenshot demo • OAuth history • OAuth 2 • OAuth in context • OAuth security model81 Copyright ©2012 Ping Identity Corporation. All rights reserved.81 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • 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 here82 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • 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 tokens83 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • 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.
  • 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 reference85 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • 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.
  • 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.html87 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • 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 scopes88 Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
  • 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 APIs Its all ball bearings (APIs) nowadays Brian Campbell89 @weeUnquietMind Copyright © 2012. Cloud Identity Summit. All Rights Reserved.