1. OAuth 2.0 -
Don’t Throw the Baby Out with
the Bathwater
Greg Brail
@gbrail
Ed Anuff Apigee
@edanuff @apigee

2. groups.google.com/group/api-craft

3. youtube.com/apigee

4. slideshare.net/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

7. WHAT HAPPENED?

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

28. NEXT STEPS AND
RECOMMENDATIONS

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

32. groups.google.com/group/api-craft

33. THANK YOU
Questions and ideas to:
@gbrail
@ edanuff
groups.google.com/group/api-craft