Everything OAuth

Everything OAuth Bruno Pedro 12 November 2010 http://www.ﬂickr.com/photos/yeliseev/5162195097/

Bruno Pedro A n e x p e r i e n c e d We b d e v e l o p e r a n d entrepreneur. Co-founder of tarpipe.com, a social media publishing platform. http://tarpipe.com/user/bpedro

Summary • What is OAuth? • Who’s using it? • Why use it? • The OAuth Dance • Security • Checklist

What is OAuth? “An open protocol to allow secure API authorization in a simple and standard method from desktop and web applications.” — http://oauth.net/

Some history • Concept started in November 2006 • First proposal in April 2007 • First draft in July 2007 • Released in October 2007

What is OAuth? 1. Authorization protocol (RFC 5849)

What is OAuth? 2. Built on top of Google AuthSub, Flickr Auth and others

What is OAuth? 2. Built on top of Google AuthSub, Flickr Auth and others http://tinyurl.com/3yhys4n

What is OAuth? 3. Authentication solution

What is OAuth? 4. Available for Web, desktop and also mobile and device applications

Who’s using OAuth? “the big 3”

Who’s using OAuth? “the big 3” everyone else

Why change to OAuth? • Escape the password anti-pattern

Why change to OAuth? • Escape the password anti-pattern http://tinyurl.com/3a5r2l9

Why change to OAuth? • Escape the password anti-pattern http://tinyurl.com/38o3r93 http://tinyurl.com/3a5r2l9

Why change to OAuth? • Give users more control

Why change to OAuth? • Offer detailed permissions (scopes)

Why change to OAuth? • Escape the password anti-pattern • Give users more control • Offer detailed permissions (scopes) • So, how does it work?

O AU TH http://www.ﬂickr.com/photos/pagedooley/2811155022/

The OAuth dance consumer provider user

3-legged OAuth • Application acts on behalf of the user • Mostly an authorization process • An access token is required

The OAuth dance 1. Request token: consumer asks for a request token from provider consumer provider

The OAuth dance 1. Request token: consumer asks for a request token from provider ask for token consumer provider

The OAuth dance 1. Request token: consumer asks for a request token from provider ask for token consumer provider receive token

The OAuth dance 2. Authorization: consumer directs user to provider to obtain authorization user provider After authorizing, user is directed back to the consumer, using a callback URL

The OAuth dance 2. Authorization: consumer directs user to provider to obtain authorization sign in and authorize user provider After authorizing, user is directed back to the consumer, using a callback URL

The OAuth dance 2. Authorization: consumer directs user to provider to obtain authorization http://tinyurl.com/38o3r93 After authorizing you would jump back to the consumer

The OAuth dance 3. Access token: consumer asks for an access token from provider consumer provider Consumer now uses information from the user authorization

The OAuth dance 3. Access token: consumer asks for an access token from provider ask for token consumer provider Consumer now uses information from the user authorization

The OAuth dance 3. Access token: consumer asks for an access token from provider ask for token consumer provider receive token Consumer now uses information from the user authorization

The OAuth dance 4. API calls: consumer makes API calls on behalf of the user consumer provider

The OAuth dance 4. API calls: consumer makes API calls on behalf of the user consumer API call provider

OOB OAuth • Mobile and desktop applications, set- top boxes, TV sets, appliances • No callback URL • Usually displays a PIN to be entered on the application

The OAuth dance 2. Authorization: consumer asks user to manually obtain authorization sign in and authorize user provider After authorizing, user is shown a PIN to be entered on the consumer

The OAuth dance 2. Authorization: consumer asks user to manually obtain authorization http://tinyurl.com/3y4hf32 After authorizing you would enter the PIN on the application

The OAuth dance 3. Access token: consumer asks for an access token from provider ask for token consumer provider receive token Consumer now uses information from the user authorization

The OAuth dance 4. API calls: consumer makes API calls on behalf of the user consumer API call provider

2-legged OAuth • No access token is required • Used mostly for direct authentication • The consumer doesn’t act on behalf of any users • The consumer is the user

The OAuth dance 2. API calls: consumer is now free to make any API calls consumer API call provider

4-legged OAuth • 4th entity: the delegator • The delegator veriﬁes user identity with the provider • Twitter calls it OAuth Echo • Example application: twitpic

The OAuth dance consumer delegator user provider

The OAuth dance 1. Access token: consumer already has the user access token access token consumer Most probably obtained from a previous 3-legged OAuth dance

The OAuth dance 2. API calls: consumer makes API calls to the delegator on behalf of the user API call consumer delegator service provider verify credentials

The OAuth dance 3. Verify identity: delegator asks the provider to verify the user identity verify identity delegator provider identity veriﬁed Delegator can now carry on with the consumer API call

xAuth • Exclusive to twitter (AFAIK) • Exchanges usernames and passwords for access tokens • Skips steps 1 and 2 of the dance • Used mostly during the OAuthpocalypse

The OAuth dance 1. Access token: consumer asks for an access token from provider username and password ask for token consumer provider receive token Consumer now uses information from the user authorization

OAuth security • What is a nonce? http://en.wikipedia.org/wiki/Cryptographic_nonce

OAuth security • Callbacks and verification codes • introduced by OAuth 1.0a • guarantees that the callback is the same specified by the consumer • sends a verifiable code with the callback

OAuth security • Always encrypt stored OAuth credentials

OAuth security • Generate veriﬁable consumer keys and secrets • by using checksum algorithms • avoid checking key validity against a database

OAuth 2.0

OAuth 2.0 • IETF draft from July 2010 • Will probably launch on 2010 • Not backwards compatible! • Already used by 37Signals, Facebook and others

OAuth 2.0 • Much simpler than original OAuth • Removed cryptographic complexity • Introduces 6 new ﬂows

OAuth 2.0 flows • User-agent flow: for clients running on a Web browser • Web-server flow: for server-side, Web applications • Device flow: for clients running on limited devices

OAuth 2.0 flows • Username and password flow: when the user trusts the consumer • Client credentials flow: similar to the original 2-legged OAuth • Assertion flow: the consumer presents a SAML assertion in exchange for an access token

The OAuth checklist • Remove passwords from API calls • Use a well tested OAuth library • Choose the appropriate dance • Encrypt all stored OAuth credentials • Use checksums on your keys

Questions? Thank you!

Everything OAuth

by Bruno Pedro on Nov 12, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

1 Embed 72

Statistics

Everything OAuth — Presentation Transcript