Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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


Published on

Published in: Technology
  • @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  Yes  No
    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  Yes  No
    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  Yes  No
    Your message goes here
  • <br /><iframe width="350" height="288" src="" frameborder="0"></iframe>
    Are you sure you want to  Yes  No
    Your message goes here
  • Quick question: why do you advise on not using refresh tokens?
    Are you sure you want to  Yes  No
    Your message goes here

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

  1. OAuth 2.0 -Don’t Throw the Baby Out withthe BathwaterGreg Brail@gbrailEd Anuff Apigee@edanuff @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:
  25. Status of big APIsProvider Spec Revision ReferenceFoursquare 10 10 unts/docs/ OAuth2Facebook 10* ocs/ authentication/Windows Live 10 10 7 uth/Geoloqi 10 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
  33. THANK YOUQuestions and ideas to:@gbrail@