Upload
apigee
View
10.185
Download
0
Tags:
Embed Size (px)
Citation preview
OAuth 2.0 - Don’t Throw the Baby Out with the Bathwater
Apigee@apigee
Greg Brail@gbrail
Ed Anuff@edanuff
groups.google.com/group/api-craft
youtube.com/apigee
slideshare.net/apigee
@edanuffEd Anuff
@gbrailGreg Brail
What happened?
OAuth 2.0 refresher course
OAuth in the world
Next steps and recommendations
Overview
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
What happened?
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
Why does it matter?
OAUTH 1.0 & 2.0 RECAP
Start with:Application credentials (ID and secret)Authenticate the userWeb browser redirectGet a token and secretSign with it on every request
OAuth 1.0a recap
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
What was wrong with OAuth 1.0?
A family of specs
The “authorization framework”
Bearer token spec
SAML, JWT, and other token specs
More specs
What is OAuth 2.0?
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
What does it really do?
In OAuth 2.0, “app credentials” are essentially a username / password that identifies a single application
OAuth 2.0 grant types
Grant Type What You Need How You Authenticate User
Authorization Code App CredentialsEnd-user credentials
Web browser redirect. Web app determines what is required
Implicit Grant App CredentialsEnd-user credentials
Web browser redirect optimized for script-heavy web apps
Resource Owner App CredentialsEnd-user username / password
Send username / password in API call
Client Credentials App Credentials You don’t
Extensions SAML token, JSON web token Depends on the extension spec
For reference: OAuth 1.0 only supported a “Mac” style of token
OAuth 2.0 token types
Token Type What it Is Signed? Spec Status
Bearer A big random number
N Proposed Standard
HTTP-MAC Signed request Y Very old
Security considerations
Token Type On the Wire On the Disk
Bearer Totally open – requires SSL to prevent token theft or misuse
Hash it just like a password
“Mac” Secure – secret cannot be reverse engineered and “nonce” prevents replay. No SSL required.
Server must access it in clear text
Three grant types require user authenticationMany people call these “three-legged”They involve the app, the API, and the user
One does not – it just uses the app credentialsMany people call this “two-legged”
Minor fact – the words “leg” and “legged” are not present in the spec
What about “legs?”
Every OAuth 2.0 token can have “scopes”
Identify what the token can doFor instance:
READ, WRITE, DELETEor
SEND_SMS, SEND_MMS, GET_LOCATION, PAY
Scopes
APIs may return two tokensAccess token with an expiration timeRefresh token with no expiration time
Refresh token used to get a new access tokenNo additional user authentication is required
Refresh tokens
What if the access token is compromised?Harder to guess if it has an expiration timeHarder to use a stolen token from a device
So why is the refresh token harder to steal?It isn’tIt’s still stored on the device or web server
Why refresh tokens?
It supports a two-tier architecture:Authorization grants, token generation,
and all that on a complex, slow serverAccess tokens in a scalable caching layerNo need for complex cache invalidation
What if the main OAuth system already scales?Then there is no reason to use refresh tokens
Why refresh tokens, really?
OAUTH IN THE WORLD
There are many more specs – check the IETF process:
http://tools.ietf.org/wg/oauth/
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. Draft2. Proposed Standard3. Draft Standard4. Internet Standard
Thanks to Aaron Parecki from Geoloqi for this table
Status of big APIs
Provider Spec Revision Reference
Foursquare 10 http://aaron.pk/2YS
Google 10 https://developers.google.com/accounts/docs/OAuth2
Facebook 10* https://developers.facebook.com/docs/authentication/
Windows Live 10 http://aaron.pk/2YV
Salesforce 10 http://aaron.pk/2YW
GitHub 7 http://developer.github.com/v3/oauth/
Geoloqi 10 https://developers.geoloqi.com/api
31 Apigee Enterprise customers use OAuth 2.020 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 onlyUsername / passwordSSL, many other options
OAuth in production - versions
Thanks to Amit Chakraborty from Apigee for this data
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 browserMany different ways to implement it
Two more steps to OAuth
NEXT STEPS ANDRECOMMENDATIONS
For web apps that use APIsOAuth is the most standard, secure choice
For mobile / native apps that use APIsOAuth has advantages over alternatives
Uniquely identifies the end user, device, and appCredentials may be revoked at any time
For server-to-server APIsUse OAuth if you use it for other things too
Why use OAuth?
Stick with the basics:
Bearer tokens
No refresh tokens
No extensions
Keeping OAuth under control
Questions
groups.google.com/group/api-craft
THANK YOUQuestions and ideas to:
@gbrail@ edanuff
groups.google.com/group/api-craft