OAuth - Don’t Throw the Baby Out with the Bathwater
Download as PPTX, PDF15 likes13,370 views
This document discusses OAuth 2.0 and provides recommendations for its use. It summarizes the history of OAuth 1.0 and 2.0, key concepts of OAuth 2.0 like grant types and token types, and real-world usage by major APIs. It recommends sticking to the basic OAuth 2.0 standard without extensions like refresh tokens for most use cases, and authenticating users through existing authentication mechanisms rather than custom implementations.
OAuth - Don’t Throw the Baby Out with the Bathwater
- 1. OAuth 2.0 - Don’t Throw the Baby Out with the Bathwater Greg Brail @gbrail Ed Anuff Apigee @edanuff @apigee
- 5. @edanuff @gbrail Ed Anuff Greg Brail
- 6. Overview What happened? OAuth 2.0 refresher course OAuth in the world Next steps and recommendations
- 8. What happened? Eran Hammer-Lahav, one of the spec leads, quit He blogged about how screwed up OAuth 2.0 is He got a lot of attention Some 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 recap Start 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 the street” about OAuth and you will get some version of this response
- 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 authentication Optionally authenticate the user There are many “grant types” that define this Get an “access token” Uniquely identifies the user / application / device Send the access token on every request
- 15. OAuth 2.0 grant types Grant Type What You Need How You Authenticate User Authorization Code App Credentials Web browser redirect. Web End-user credentials app determines what is required Implicit Grant App Credentials Web browser redirect End-user credentials optimized for script-heavy web apps Resource Owner App Credentials Send username / password in End-user username / password API call Client Credentials App Credentials You don’t Extensions SAML token, JSON web token Depends on the extension spec In OAuth 2.0, “app credentials” are essentially a username / password that identifies a single application
- 16. OAuth 2.0 token types Token Type What it Is Signed? Spec Status Bearer A big random N Proposed Standard number HTTP-MAC Signed request Y Very old For reference: OAuth 1.0 only supported a “Mac” style of token
- 17. Security considerations Token Type On the Wire On the Disk Bearer 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 user One 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. Scopes Every OAuth 2.0 token can have “scopes” Identify what the token can do For instance: READ, WRITE, DELETE or SEND_SMS, SEND_MMS, GET_LOCATION, PAY
- 20. Refresh tokens APIs may return two tokens Access token with an expiration time Refresh token with no expiration time Refresh 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 device So 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 invalidation What if the main OAuth system already scales? Then there is no reason to use refresh tokens
- 23. OAUTH IN THE WORLD
- 24. Status of key specs Spec Revision Status Authorization Framework 31 Proposed Standard Bearer Token 23 Proposed Standard JWT Token 3 Draft JWT Bearer Token 1 Draft SAML 2 Token 13 Draft HTTP MAC Token 1 Draft; Last update February How a spec grows up to become a “law:” 1. Draft 2. Proposed Standard 3. Draft Standard 4. Internet Standard There are many more specs – check the IETF process: http://tools.ietf.org/wg/oauth/
- 25. Status of big APIs Provider Spec Revision Reference Foursquare 10 http://aaron.pk/2YS Google 10 https://developers.google.com/acco unts/docs/ OAuth2 Facebook 10* https://developers.facebook.com/d ocs/ authentication/ Windows Live 10 http://aaron.pk/2YV Salesforce 10 http://aaron.pk/2YW GitHub 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 - versions 31 Apigee Enterprise customers use OAuth 2.0 20 have “two-legged OAuth” aka “client credentials” 19 have “three-legged OAuth” 8 have both 6 Customers have OAuth 1.0a Many 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 OAuth It’s not just about tokens How is the user authenticated? All but two Apigee customers use existing web pages or directory servers for user authentication How 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 choice For 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 time For server-to-server APIs Use OAuth if you use it for other things too
- 30. Keeping OAuth under control Stick with the basics: Bearer tokens No refresh tokens No extensions
- 31. Questions
- 33. THANK YOU Questions and ideas to: @gbrail @ edanuff groups.google.com/group/api-craft
Editor's Notes
- #2: Creative Commons Attribution-Share Alike 3.0 United States License