OAuth - Don’t Throw the Baby Out with the Bathwater
Upcoming SlideShare
Loading in...5

Like this? Share it with your network


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






Total Views
Views on SlideShare
Embed Views



41 Embeds 4,546

http://blog.apigee.com 1916
http://apigee.com 1828
http://blog.programmableweb.com 376
https://blog.apigee.com 116
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://mktg-dev.apigee.com 9
https://jabbr.net 8
http://jabbr.net 8
http://www.caucapino4u.com 7
http://core.traackr.com 7
http://ip54.216-86-157.static.steadfast.net 6
https://twimg0-a.akamaihd.net 5
http://ip52.216-86-157.static.steadfast.net 5
http://7971561969950620294_53bff2a1705b38e92c805355b2367b95f12655f0.blogspot.com 5
https://si0.twimg.com 5
http://webcache.googleusercontent.com 5
http://blog.pheromonic.com 5
http://newsblur.com 5
http://www.hanrss.com 4
http://www.tuicool.com 4
http://internettech.collected.info 4
http://localhost 3
https://abs.twimg.com 2
http://www.programmableweb.com 2
http://feeds.feedburner.com 2
http://freerss.net 2
http://edit.apigee.net 1
http://rss2.com 1
http://mktg-new.local 1
http://www.voidstar.com 1
http://www.onlydoo.com 1
https://www.facebook.com 1
http://altblog.nypirateparty.com 1
http://blogwatcher.thebaileys.name 1
http://www.one-tab.com 1



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
  • @kalsze 'Credentials' is a more generic term. In other words, a username / password is a subset of 'credentials.'

    I don't actually remember exactly how we used the term in the webinar but it actually could make a difference.

    For instance, the 'authorization code' grant type redirects to the user to a web page, where the user is required to authenticate. It's up to the web page, so the page can choose any 'credentials' it wants to use, including username / password, SSL cert, rolling security token (like Google Authenticator or SecurID) etc.

    On the other hand, OAuth 2.0 also has the 'resource owner password credentials' grant type, which like its name implies, allows the client to make an API call to the server that includes a username and password, and returns a token.
    Are you sure you want to
    Your message goes here
  • On slide 15, in the column 'What You Need', what's the difference between 'End-user credentials' and 'End-user username / password'?
    Are you sure you want to
    Your message goes here
  • I don't think that refresh tokens add any security -- the client still has to store them securely and can use a refresh token to get an access token with no additional authentication. So it's the same as an access token on the wire, and on the client from that perspective.

    The main purpose of the refresh token was to allow OAuth implementations to have a separate tier in their architecture that validates and caches access tokens in a very dumb way, and then delegate user authentication to a separate server.

    So to accomplish this, which can make things easier for the API provider, the API users (the developers) need to track token expiration, use their refresh token to get a new token before the access token expires, and coordinate all that so that it doesn't impact the flow of API traffic from their client.

    I personally think that a better approach is to set an expiration time on access tokens that works for your security policy depending on what you're trying to do, and periodically re-authenticate the user.
    Are you sure you want to
    Your message goes here
  • <br /><iframe width="350" height="288" src="http://www.youtube.com/embed/a2Et0bAK8kE" frameborder="0"></iframe>
    Are you sure you want to
    Your message goes here
  • Quick question: why do you advise on not using refresh tokens?
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment
  • Creative Commons Attribution-Share Alike 3.0 United States License

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

  • 1. OAuth 2.0 -Don’t Throw the Baby Out withthe BathwaterGreg Brail@gbrailEd Anuff Apigee@edanuff @apigee
  • 2. groups.google.com/group/api-craft
  • 3. youtube.com/apigee
  • 4. slideshare.net/apigee
  • 5. @edanuff @gbrailEd Anuff Greg Brail
  • 6. OverviewWhat happened?OAuth 2.0 refresher courseOAuth in the worldNext steps and recommendations
  • 8. 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
  • 9. 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
  • 10. OAUTH 1.0 & 2.0 RECAP
  • 11. 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
  • 12. 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
  • 13. What is OAuth 2.0?A family of specs The “authorization framework” Bearer token spec SAML, JWT, and other token specs More specs
  • 14. 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
  • 15. 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
  • 16. 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
  • 17. 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.
  • 18. 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
  • 19. 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
  • 20. 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
  • 21. 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
  • 22. 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
  • 24. 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/
  • 25. 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
  • 26. 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
  • 27. 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
  • 29. 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
  • 30. Keeping OAuth under controlStick with the basics: Bearer tokens No refresh tokens No extensions
  • 31. Questions
  • 32. groups.google.com/group/api-craft
  • 33. THANK YOUQuestions and ideas to:@gbrail@ edanuffgroups.google.com/group/api-craft