1. OAuth 1.0
An Open API Authorization Standard
@nov
2010 9 2
2. @nov
• Web Developer @ Smart.fm
• Smart.fm API (OAuth Server)
• Integration with other APIs (OAuth Client)
• OAuth.jp
• OAuth Japan - Google Groups
• OpenID Foundation Japan WG
• The OAuth 1.0 Protocol
2010 9 2
6. APIs for 3rd-party enable..
• Access to "protected resources"
• profile information
• email, contact list
• status update
• payment
• Needs ”Access Control”
2010 9 2
7. Access Control for APIs
• Access Control
• Authentication
• Authorization
• + alpha
• For APIs
• Users won’t involve every time
2010 9 2
8. Basic Authentication
• easy to use
• just input username & password
• easy to understand
• yes, you are logging-in!
• widely supported
• IE6 also support it!!
2010 9 2
11. The migration from basic auth isn't an issue of
protecting from man-in-the-middle attacks (such that
SSL would prevent) but more of an issue with
applications having access to Twitter usernames and
passwords.
There are many people who use the same passwords
across multiple sites, so the security risk of supporting
basic auth does not stop at Twitter.
by Taylor Singletary from Twitter Inc.
2010 9 2
12. Is your mixi password different with Twitter's one?
How about Google, Amazon or Paypal?
2010 9 2
13. Use different password on each service!
... but can you remember more than 10 passwords?
2010 9 2
16. o rd !?
passw
m y
e re is
W h
EVERYWHERE!!
2010 9 2
17. Anti-password
• Google AuthSub, Yahoo! BBAuth, Flickr API Auth etc.
• Stop to share password
• Token based
• Secure
• But not standardized
2010 9 2
19. OAuth 1.0
An Open API Authorization Standard
2010 9 2
20. OAuth 1.0
• Published by community in October 2007 (Final Draft)
• RFC5849 in April 2010
• Supported widely by big players
• Twitter, Google, Yahoo! etc.
2010 9 2
21. OAuth Scenario
• User approves 3rd party applications access
• Without share his/her password
• How API provider knows the approval?
• 3rd party applications access to the API
• Prove pre-gained user approval
• How 3rd-party proves user approval?
2010 9 2
22. 3 Roles
• User (Resource Owner)
• You
• Consumer (Client)
• Twitter client on your iPhone
• Service Provider (Server)
• Twitter
2010 9 2
23. 3 Kind of Tokens (credentials)
• Consumer Key & Secret (Client Credentials)
• ID & Password of Consumer
• Request Token & Secret (Temporary Credentials)
• Used during approval process
• For session management
• Access Token & Secret (Token Credentials)
• Represent the user approval
2010 9 2
24. 3 Steps
• Step 0
• Consumer registration (out of scope)
• Step 1
• Consumer gets User approval
• Step 2
• Consumer accesses to the protected resources on
Service Provider on behalf of User
2010 9 2
25. Step 0: Consumer Registration
• Not standardized yet
• Go developer site
• Twitter => http://developer.twitter.com
• Facebook => http://developers.facebook.com
• Yahoo! US => http://developer.yahoo.com
• Yahoo! Japan => http://developer.yahoo.co.jp
• Google => Google ”google oauth”
2010 9 2
28. Step 1: Get User Approval
• Step 1.0: User let Consumer start OAuth dance
• Step 1.1: Consumer gets unauthorized Request Token
• Step 1.2: Consumer redirects User to Service Provider with
unauthorized Request Token
• Step 1.3: User approves Consumer access, Service Provider
marks Request Token authorized
• Step 1.4: Service Provider redirects User to Consumer with
authorized Request Token
• Step 1.5: Consumer exchanges authorized Request Token
with Access Token
2010 9 2
29. User Consumer Service Provider
Dance Start!
Establish Request Token
Redirect with unauthorized Request Token
Approve Consumer access Authorized!
Redirect with authorized Request Token
Exchange it with Access Token
2010 9 2
30. User Consumer Service Provider
Dance Start!
Establish Request Token
Redirect with unauthorized Request Token
Approve Consumer access Authorized!
Redirect with authorized Request Token
Exchange it with Access Token
2010 9 2
31. Step 1.1: Get Request Token
• Consumer requests to Service Provider
• POST to Request Token URL
• Include protocol parameters in Authorization header
2010 9 2
32. OAuth Protocol Parameters
• realm
• The scope of access control
• oauth_consumer_key
• Identifier of Consumer
• oauth_signature, oauth_signature_method
• Used for request verification
2010 9 2
33. OAuth Protocol Parameters
• oauth_nonce
• Nonce is unique in each request from Consumer
• Against replay attack
• oauth_timestamp
• Service Provider clears out nonces after certain time
period
• oauth_callback
• The endpoint where Service Provider let User
redirect back later
2010 9 2
34. Step 1.1: Get Request Token
• Service Provider responses to Consumer
• Include Request Token in response body
• application/x-www-form-urlencoded
2010 9 2
35. OAuth Protocol Parameters
• oauth_token, oauth_token_secret
• Request Token, Request Token Secret
• Used for session management during OAuth dance
• oauth_callback_confirmed
• Always true
• Differentiate legacy OAuth 1.0 and OAuth 1.0a
• There is a long history..
2010 9 2
36. User Consumer Service Provider
Dance Start!
Establish Request Token
Redirect with unauthorized Request Token
Approve Consumer access Authorized!
Redirect with authorized Request Token
Exchange it with Access Token
2010 9 2
37. Step 1.2: Redirect to Service Provider
• Consumer let User redirect to Authorize URL
• Include Request Token in query string
2010 9 2
38. User Consumer Service Provider
Dance Start!
Establish Request Token
Redirect with unauthorized Request Token
Approve Consumer access Authorized!
Redirect with authorized Request Token
Exchange it with Access Token
2010 9 2
40. User Consumer Service Provider
Dance Start!
Establish Request Token
Redirect with unauthorized Request Token
Approve Consumer access Authorized!
Redirect with authorized Request Token
Exchange it with Access Token
2010 9 2
41. Step 1.4: Redirect back to Consumer
• Service Provider let User redirect back to Consumer
• Redirect to ”oauth_callback” Consumer specified
• Include Request Token and verifier in query string
2010 9 2
42. OAuth Protocol Parameters
• oauth_verifier
• Used when establishing Access Token
• Against session fixation attack
• Yeah, it’s a long history..
2010 9 2
43. User Consumer Service Provider
Dance Start!
Establish Request Token
Redirect with unauthorized Request Token
Approve Consumer access Authorized!
Redirect with authorized Request Token
Exchange it with Access Token
2010 9 2
44. Step 1.5: Establish Access Token
• Consumer requests to Service Provider
• POST to Access Token URL
• Include protocol parameters in Authorization header
2010 9 2
45. Step 1.5: Establish Access Token
• Service Provider responses to Consumer
• Include Access Token in response body
• application/x-www-form-urlencoded
2010 9 2
46. OAuth Protocol Parameters
• oauth_token, oauth_token_secret
• Access Token, Access Token Secret
• Represent User approval
• Used to prove User approval when accessing API
• Available until expired or revoked (in many cases)
2010 9 2
47. User Consumer Service Provider
Dance Start!
Establish Request Token
Redirect with unauthorized Request Token
Approve Consumer access Authorized!
Redirect with authorized Request Token
Exchange it with Access Token
2010 9 2
64. Signature Verification
• Consumer sign the request
• Service Provider re-generate signature based on the
request, and compare it with ”oauth_signature”
• If matched, it’s OK
• If not, 401 signature_invalid
• Request had been tempered?
• Consumer/Service Provider’s bug?
• Debugging on Consumer side is painful...
2010 9 2
66. When you got 401
• Check error response body
• Ask others
• OAuth - Google Groups
• OAuth Japan - Google Groups
• Twitter Development Talk - Google Groups
• Facebook Developers Forum
2010 9 2
