OAuth - Don’t Throw the Baby Out with the Bathwater

OAuth 2.0 -Don’t Throw the Baby Out withthe BathwaterGreg Brail@gbrailEd Anuff Apigee@edanuff @apigee

groups.google.com/group/api-craft

youtube.com/apigee

slideshare.net/apigee

@edanuff @gbrailEd Anuff Greg Brail

OverviewWhat happened?OAuth 2.0 refresher courseOAuth in the worldNext steps and recommendations

WHAT HAPPENED?

What happened?Eran Hammer-Lahav, one of the spec leads, quitHe blogged about how screwed up OAuth 2.0 isHe got a lot of attentionSome other people blogged about his blog

Why does it matter?One of the primary authors of OAuth 2.0 disowned it.So is this an excuse to give up on OAuth?We don’t think so

OAUTH 1.0 & 2.0 RECAP

OAuth 1.0a recapStart with: Application credentials (ID and secret) Authenticate the user Web browser redirect Get a token and secret Sign with it on every request

What was wrong with OAuth 1.0?Signatures are hard This may seem minor but ask the “developer on thestreet” about OAuth and you will get some version of thisresponse

What is OAuth 2.0?A family of specs The “authorization framework” Bearer token spec SAML, JWT, and other token specs More specs

What does it really do?Start with “client credentials” These identify the application requesting authenticationOptionally authenticate the user There are many “grant types” that define thisGet an “access token” Uniquely identifies the user / application / deviceSend the access token on every request

OAuth 2.0 grant typesGrant Type What You Need How You Authenticate UserAuthorization Code App Credentials Web browser redirect. Web End-user credentials app determines what is requiredImplicit Grant App Credentials Web browser redirect End-user credentials optimized for script-heavy web appsResource Owner App Credentials Send username / password in End-user username / password API callClient Credentials App Credentials You don’tExtensions SAML token, JSON web token Depends on the extension specIn OAuth 2.0, “app credentials” are essentiallya username / password that identifies a single application

OAuth 2.0 token typesToken Type What it Is Signed? Spec StatusBearer A big random N Proposed Standard numberHTTP-MAC Signed request Y Very old For reference: OAuth 1.0 only supported a “Mac” style of token

Security considerationsToken Type On the Wire On the DiskBearer Totally open – requires SSL to Hash it just like a password prevent token theft or misuse“Mac” Secure – secret cannot be reverse Server must access it in clear engineered and “nonce” prevents text replay. No SSL required.

What about “legs?”Three grant types require user authentication Many people call these “three-legged” They involve the app, the API, and the userOne does not – it just uses the app credentials Many people call this “two-legged”Minor fact – the words “leg” and “legged” are not present in the spec

ScopesEvery OAuth 2.0 token can have “scopes”Identify what the token can doFor instance: READ, WRITE, DELETEor SEND_SMS, SEND_MMS, GET_LOCATION, PAY

Refresh tokensAPIs may return two tokens Access token with an expiration time Refresh token with no expiration timeRefresh token used to get a new access token No additional user authentication is required

Why refresh tokens?What if the access token is compromised? Harder to guess if it has an expiration time Harder to use a stolen token from a deviceSo why is the refresh token harder to steal? It isn’t It’s still stored on the device or web server

Why refresh tokens, really?It supports a two-tier architecture: Authorization grants, token generation, and all that on a complex, slow server Access tokens in a scalable caching layer No need for complex cache invalidationWhat if the main OAuth system already scales? Then there is no reason to use refresh tokens

OAUTH IN THE WORLD

Status of key specsSpec Revision StatusAuthorization Framework 31 Proposed StandardBearer Token 23 Proposed StandardJWT Token 3 DraftJWT Bearer Token 1 DraftSAML 2 Token 13 DraftHTTP MAC Token 1 Draft; Last update FebruaryHow a spec grows up to become a “law:”1. Draft2. Proposed Standard3. Draft Standard4. Internet Standard There are many more specs – check the IETF process: http://tools.ietf.org/wg/oauth/

Status of big APIsProvider Spec Revision ReferenceFoursquare 10 http://aaron.pk/2YSGoogle 10 https://developers.google.com/acco unts/docs/ OAuth2Facebook 10* https://developers.facebook.com/d ocs/ authentication/Windows Live 10 http://aaron.pk/2YVSalesforce 10 http://aaron.pk/2YWGitHub 7 http://developer.github.com/v3/oa uth/Geoloqi 10 https://developers.geoloqi.com/api Thanks to Aaron Parecki from Geoloqi for this table

OAuth in production - versions31 Apigee Enterprise customers use OAuth 2.0 20 have “two-legged OAuth” aka “client credentials” 19 have “three-legged OAuth” 8 have both6 Customers have OAuth 1.0aMany customers have neither “API Key” authentication only Username / password SSL, many other options Thanks to Amit Chakraborty from Apigee for this data

Two more steps to OAuthIt’s not just about tokensHow is the user authenticated? All but two Apigee customers use existing web pages or directory servers for user authenticationHow is consent granted to issue the token? Usually done through the browser Many different ways to implement it

NEXT STEPS ANDRECOMMENDATIONS

Why use OAuth?For web apps that use APIs OAuth is the most standard, secure choiceFor mobile / native apps that use APIs OAuth has advantages over alternatives Uniquely identifies the end user, device, and app Credentials may be revoked at any timeFor server-to-server APIs Use OAuth if you use it for other things too

Keeping OAuth under controlStick with the basics: Bearer tokens No refresh tokens No extensions

Questions

groups.google.com/group/api-craft

THANK YOUQuestions and ideas to:@gbrail@ edanuffgroups.google.com/group/api-craft

http://blog.apigee.com	1916
http://apigee.com	980
http://blog.programmableweb.com	343
http://feeds.apigee.com	90
http://blog.sonoasystems.com	43
http://blog-dev.wearepropeople.md	20
http://mktg-dev.wearepropeople.md	14
http://blog-dev.apigee.com	11
http://blog.edit.apigee.net	11
http://feeds2.feedburner.com	9
http://jabbr.net	8
https://jabbr.net	8
http://core.traackr.com	7
http://www.caucapino4u.com	7
http://ip54.216-86-157.static.steadfast.net	6
http://newsblur.com	5
http://ip52.216-86-157.static.steadfast.net	5
http://7971561969950620294_53bff2a1705b38e92c805355b2367b95f12655f0.blogspot.com	5
http://blog.pheromonic.com	5
http://webcache.googleusercontent.com	5
https://twimg0-a.akamaihd.net	5
https://si0.twimg.com	5
http://www.hanrss.com	4
http://internettech.collected.info	4
http://localhost	3
http://feeds.feedburner.com	2
http://freerss.net	2
https://abs.twimg.com	2
http://edit.apigee.net	1
http://www.onlydoo.com	1
http://www.voidstar.com	1
http://altblog.nypirateparty.com	1
http://blogwatcher.thebaileys.name	1
http://mktg-dev.apigee.com	1

OAuth - Don’t Throw the Baby Out with the Bathwater

by Apigee on Aug 02, 2012

Accessibility

Categories

Upload Details

Usage Rights

34 Embeds 3,531

Statistics

OAuth - Don’t Throw the Baby Out with the Bathwater Presentation Transcript