OAuth 101 & Secure APIs 2012 Cloud Identity Summit

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.

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

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

Draft -28 of The OAuth 2.0 Authorization Framework

4


5 Page 70


Prominently mentioned
in the second to last
paragraph of the very
last page.

6 Page 70

Better Placement on Some Lesser Known Specs

7

Some Might Even Call Them Esoteric…

8

Agenda
• Introduction
• OAuth drivers
• Screenshot demo
• OAuth history
• OAuth 2

9

Drivers

10

In the Beginning there was SOAP…

Simple [sic] Object Access Protocol
… and SOAP based SOA was going to change the world

11

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

However…

Apparently people are lazy and really like to REST…
13

But just for some perspective…

14

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

2) Password anti-pattern

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

16

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

Importance of revocation

18

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

Cloud Cures Everything!

19

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

4) The Rise of Native Mobile Apps

• Typically interact
with internet APIs
• Require
authentication &
authorization

21

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

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

Drivers

Password
Lack of anti-
standards pattern

Cloud
Native
APIs
mobile
Applications

24

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

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

Agenda
• Introduction
• OAuth drivers
• Screenshot demo
• OAuth history
• OAuth 2

27

Screenshot Demo: brizzly.com accesses the twitters

API @
brizzly.com
Twitter

Web Interface

28

About Brizzly… Remember Revocation?

29

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

30


31


32


33


34


35


36


37

Agenda
• Introduction
• OAuth drivers
• Screenshot demo
• OAuth history
• OAuth 2

38

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

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

Agenda
• Introduction
• OAuth drivers
• Screenshot demo
• OAuth history
• OAuth 2

41

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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
Authorization: MAC id="jd93dh9dh39D",
nonce="273156:di3hvdf8",
bodyhash="k9kbtCIy0CkI3/FEfpS/oIDjk6k=",
mac="W7bdMZbv9UWOTadASIQHagZyirA="

57

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

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
Authorization: Bearer gBjAAf7Io0FIfwZaXDTRQg0d7GTwAOL7G6e
59

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

Exchange Resource Owner Password Credentials for Access Token

Authorization: Basic c29tZWNsaWVudDpBbWVyaWNhJ3NIYXQ=

grant_type=password&username=pmadsen&password=uselesstaxonomy

HTTP/1.1 200 OK
Pragma: no-cache
Content-Type: application/json; charset=UTF-8

{
"access_token":"a0VuzD3NfDsjCsTUZB5LmXs7WPQ1x07DCHR”,
"expires_in":3600,
"refresh_token":"mSTBpqQcSkRECNfDclfRDjREnmqeWVap0DseM6aXkixIX”
}

61

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

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

Refreshing an Access Token

Authorization: Basic c29tZWNsaWVudDpBbWVyaWNhJ3NIYXQ=

grant_type=refresh_token&refresh_token=1StDpqQcSk1CNf7clfRjREnmqeiVap0DseM6aXkixI11

HTTP/1.1 200 OK
Pragma: no-cache
Content-Type: application/json; charset=UTF-8

{
"access_token":"MdqBuexXYlMSogbrAwiPP47eGxGqZajuJNa”,
"expires_in":3600,
"refresh_token":"hlyEOO9PXgmvPiYI8g68KSEs2HQhgrkiUQGsc9Xxskd”
}

64

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

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

Agenda
• Introduction
• OAuth drivers
• Screenshot demo
• OAuth history
• OAuth 2

67

OAuth in Context

Compare, Contrast & Compose

68

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

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

OpenID Connect Family tree

Artifact

Hybrid
Extension

OAuth 1

OAuth 2 JWT
71

72

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

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

Sequencing SAML & OAuth

OAuth

SAML

OAuth

75

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

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

SAML

POST /token.oauth2 HTTP/1.1
Host: authz.example.net

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

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer
&assertion=eyJhbGciOiJFUzI1NiJ9.eyJpc3Mi[...omitted for brevity...].J9lZhwP_2n[...omitted...]

77

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

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

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

Agenda
• Introduction
• OAuth drivers
• Screenshot demo
• OAuth history
• OAuth 2

81

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

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

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

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

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

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

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

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

OAuth 101 & Secure APIs 2012 Cloud Identity Summit

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a OAuth 101 & Secure APIs 2012 Cloud Identity Summit

Similar a OAuth 101 & Secure APIs 2012 Cloud Identity Summit (20)

Más de Brian Campbell

Más de Brian Campbell (16)

Último

Último (20)

OAuth 101 & Secure APIs 2012 Cloud Identity Summit