OAuth 101 & Secure APIs 2012 Cloud Identity Summit

Copyright © 2012. Cloud Identity Summit. All Rights Reserved.

1

OAuth 101 & Secure API'sIt's all ball bearings (APIs) nowadays

An authentication and authorization framework for the future of the Interwebs

Brian Campbell@weeUnquietMind


2Copyright ©2012 Ping Identity Corporation. All rights reserved.2

Agenda• Introduction• OAuth drivers• Screenshot demo• OAuth history• OAuth 2 • OAuth in context• OAuth security model



Who the heck is this guy anyway?

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.

@weeUnquietMind – the short story of an unfortunate handle


4

Draft -28 of The OAuth 2.0 Authorization FrameworkS

TR

EE

T C

RE

D


5


TR

EE

T C

RE

D

Page 70


6


TR

EE

T C

RE

D

Prominently mentioned in the second to last

paragraph of the very last page.

Page 70



Better Placement on Some Lesser Known Specs



Some Might Even Call Them Esoteric…






Drivers



In the Beginning there was SOAP…

… and SOAP based SOA was going to change the world

Simple [sic] Object Access Protocol



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


13

However…

Apparently people are lazy and really like to REST…


14

But just for some perspective…


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


16

2) Password anti-pattern

Other sites asks YOU for your GOOGLE password so it can access your Google stuff.

What could go wrong?


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


18

Importance of revocation



3) Cloud! CLOUD! CLOUD! CLOUD! CLOUD! APIs

Cloud Cures Everything!



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


21

4) The Rise of Native Mobile Apps#B

YM

OD

D

(Brin

g Yo

ur M

om O

r Dad

’s D

evic

e)

• Typically interact with internet APIs

• Require authentication & authorization



Aside: Mobile Application Continuum

Web ServerWeb Server

Web App

Mobile Device

Browser

Mobile WebPage

Web Applications

Mobile Device

Native Applications

Native App

HTML/JS/CSS JSON/XMLHybrid Approaches

Hybrid


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


24

Drivers

Lack of standards

Cloud APIs

Password anti-pattern

Native mobileApplications

OAuth


25

• 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

Enter OAuth!



An Overused AnalogyOAuth is your valet key to the Interwebs

It’s going happen one way or the other so may as well tax and regulate…





28

Screenshot Demo: brizzly.com accesses the twitters

brizzly.com@

Twitter

Web Interface

API


29

About Brizzly… Remember Revocation?


30

Screenshot Demo: (now defunct) brizzly.com accesses the twitters


31



32



33



34



35



36



37






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


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





42

• 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…

OAuth 2.0


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.


44

• 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

More Terminology: Tokens


45

• 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

Access Token Types


46

• 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

Bearer Access Tokens


47

• 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…

MAC Access Tokens


48

• 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

More Terminology: Endpoints


49

• 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

Terminology: Authorization Grant


50

• 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

Terminology: Scope


51

• 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

Some Scope Examples


52

• 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

Abstract Flow


53

• authorization code• implicit*• resource owner password credentials• client credentials• refresh token• Extensions

* one of these things is not like the others…

Authorization Grant Types


54

• 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

Grant Type: Authorization Code


55

Getting an Authorization Code

HTTP/1.1 302 FoundLocation: https://client.example.com/cb?code=GecMEdixSKRJO8xfpCXHg9Fg2Hze

Authorization Request

Authorization Response

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…]


56

Exchange Authorization Code for Access Token

POST /as/token.oauth2 HTTP/1.1Host: as.example.comContent-Type: application/x-www-form-urlencoded

client_id=aclient&client_secret=hoser&redirect_uri=https%3A//client.example.com/cb&grant_type=authorization_code&code=GecMEdixSKRJO8xfpCXHg9Fg2Hze

HTTP/1.1 200 OKCache-Control: no-storePragma: no-cacheContent-Type: application/json;charset=UTF-8 {

"token_type":"Bearer","access_token":"a0VuzD3NfDsjCsTUZB5LmXs7WPQ1x07DCHR”, "expires_in":3600,

"refresh_token":"mSTBpqQcSkRECNfDclfRDjREnmqeWVap0DseM6aXkixIX”}

Access Token Request

Access Token Response


57

Brief Interlude: Using the Access Token

GET /double/secret/probation/resource HTTP/1.1 Host: rs.example.com Authorization: Bearer a0VuzD3NfDsjCsTUZB5LmXs7WPQ1x07DCHR

Protected Resource Request with a Bearer Token

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="


58

• 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

Grant Type: Implicit


59

Getting a Token with Implicit

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

HTTP/1.1 302 FoundLocation: https://client.example.com/cb#expires_in=3600&token_type=Bearer&access_token=gBjAAf7Io0FIfwZaXDTRQg0d7GTwAOL7G6e

Authorization Request

Authorization Response

GET /double/secret/probation/resource HTTP/1.1 Host: rs.example.com Authorization: Bearer gBjAAf7Io0FIfwZaXDTRQg0d7GTwAOL7G6e

Protected Resource Request

[…magic happens…]


60

• 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

Grant Type: Resource Owner Password Credentials


61

Exchange Resource Owner Password Credentials for Access Token

POST /as/token.oauth2 HTTP/1.1Host: as.example.comAuthorization: Basic c29tZWNsaWVudDpBbWVyaWNhJ3NIYXQ=Content-Type: application/x-www-form-urlencoded

grant_type=password&username=pmadsen&password=uselesstaxonomy

HTTP/1.1 200 OKCache-Control: no-storePragma: no-cacheContent-Type: application/json; charset=UTF-8 {

"token_type":"Bearer","access_token":"a0VuzD3NfDsjCsTUZB5LmXs7WPQ1x07DCHR”, "expires_in":3600,

"refresh_token":"mSTBpqQcSkRECNfDclfRDjREnmqeWVap0DseM6aXkixIX”}




62

• 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

Grant Type: Client Credentials


63

• 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

Grant Type: Refresh Token


64

Refreshing an Access Token

POST /as/token.oauth2 HTTP/1.1Host: as.example.comAuthorization: Basic c29tZWNsaWVudDpBbWVyaWNhJ3NIYXQ=Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token&refresh_token=1StDpqQcSk1CNf7clfRjREnmqeiVap0DseM6aXkixI11

HTTP/1.1 200 OKCache-Control: no-storePragma: no-cacheContent-Type: application/json; charset=UTF-8 {

"token_type":"Bearer","access_token":"MdqBuexXYlMSogbrAwiPP47eGxGqZajuJNa”, "expires_in":3600,

"refresh_token":"hlyEOO9PXgmvPiYI8g68KSEs2HQhgrkiUQGsc9Xxskd”}




65

• 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

Extension Grant Types


66

Partial Specification Landscape

The OAuth 2.0 Authorization Frameworkdraft-ietf-oauth-v2

The OAuth 2.0 Protocol: Bearer Tokens

draft-ietf-oauth-v2-bearer

HTTP Authentication: MAC Access Authenticationdraft-ietf-oauth-v2-http-mac

SAML 2.0 Bearer Assertion Grant Type Profile for OAuth 2.0

draft-ietf-oauth-saml2-bearer

OAuth 2.0 Assertion Profile

draft-ietf-oauth-assertions

JSON Web Token (JWT) Bearer Profile for OAuth 2.0

draft-ietf-oauth-jwt-bearer

Assertions and Protocols for SAML V2.0saml-core-2.0-os

Using a TokenGetting a Token

Extension Grants &

Client AuthenticationTokens

Other ProtocolsUser-Managed Access (UMA)

Core Protocoldraft-hardjono-oauth-umacore OpenID Connect 1.0

JSON Web Token (JWT) draft-ietf-oauth-json-web-token

JSON Web Signature (JWS)draft-ietf-jose-json-web-signature

JSON Web Signature (JWE)draft-ietf-jose-json-web-encryption

JSON Web Key (JWK)draft-ietf-jose-json-web-key

JSON Web Key (JWA)draft-ietf-jose-json-web-algorithms

JOSE

XML Sec

?





68

OAuth in Context

Compare, Contrast & Compose


69

• 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

OAuth relationship to OpenID


70

• 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

OpenID Connect


71

OpenID Connect Family tree

JWT

Hybrid Extension

OAuth 1

OAuth 2

Artifact


72


73

• 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

OpenID Connect relation to OAuth


74

SAML & OAuth

SAMLOAuth

OAuthSAML

SAML OAuth

'Hybrid' – carry OAuth tokenin SAML SSO messages

SAML assertions sent within OAuth messages

'Sequencing' – use SAML SSOto authenticate user to AS


75

Sequencing SAML & OAuth

SAML

OAuth

OAuth


76

Trading Tokens

OAuth

Assertion profile

SAML JWT

Core protocol [0]

How to use assertions as a grant type [1] (also client authentication)

Profiles for specific assertionFormats [2] & [3]

[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 [3] - http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer

http://tools.ietf.org/html/draft-ietf-oauth-v2

http://tools.ietf.org/html/draft-ietf-oauth-v2

http://tools.ietf.org/html/draft-ietf-oauth-assertions

http://tools.ietf.org/html/draft-ietf-oauth-assertions

http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer

http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer

http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer




77

SAML

POST /token.oauth2 HTTP/1.1Host: authz.example.netContent-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.1Host: authz.example.netContent-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...]

Using a SAML Assertion (or JWT) as an OAuth grant type


78

• 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

OAuth relationship to XACML

Though both focused on authorization, OAuth & XACML are very different animals


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)


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





82

• 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

OAuth 2 Security Model

http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel


83

• 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

Session Cookie Analogy


84

• 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)?

What about MAC?


85

• 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

Tokens & Signing


86

• 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…

But Why aren’t Tokens Defined?


87

• 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

Not for Single Sign-On


88

• 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

Other Security Stuff


89

OAuth 101 & Secure API'sIt's all ball bearings (APIs) nowadays Brian Campbell

@weeUnquietMind

Thanks!(and time permitting)

Questions? (there are no stupid questions, only stupid answers and I’m

tremendously qualified to deliver such answers)

Technology

OAuth 101 & Secure APIs 2012 Cloud Identity Summit