oauth 1.0

OAuth 1.0An Open API Authorization Standard

2010年9月2日木曜日

• 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 翻訳

The OAuth 1.0 Protocol 翻訳http://j.mp/oauth1

GoogleMaps, Gmail, Contacts, Calender, YouTube,

AdSence, AdWords, Analytics, Checkout, Docs,FriendConnect, Social Graph, Buzz, Wave etc.

Yahoo!US: Mail, Contacts, Flickr, Delicious, Answers, Maps etc.

Japan: Auction, Shopping, Maps, Chiebukuro etc.

OthersTwitter, Facebook, MySpace, LinkedIn,

GitHub, Evernote, Dropbox, Vimeo, Tumblrmixi, mobage, gree

APIs for 3rd party

3rd-party Apps

APIs for 3rd-party enable..

• Access to "protected resources"

• profile information

• email, contact list

• status update

• payment

• Needs ”Access Control”

Access Control for APIs

• Access Control

• Authentication

• Authorization

• + alpha

• For APIs

• Users won’t involve every time

Basic Authentication

• easy to use

• just input username & password

• easy to understand

• yes, you are logging-in!

• widely supported

• IE6 also support it!!

But Basic Auth is not secure...

Basic Authenticationterminated in Twitter API

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.

Is your mixi password different with Twitter's one?How about Google, Amazon or Paypal?

Use different password on each service!... but can you remember more than 10 passwords?

Where is my password!?

EVERYWHERE!!

Anti-password

• Google AuthSub, Yahoo! BBAuth, Flickr API Auth etc.

• Stop to share password

• Token based

• Secure

• But not standardized

Let’s make API authentication standard

OAuth 1.0An Open API Authorization Standard

OAuth 1.0

• Published by community in October 2007 (Final Draft)

• RFC5849 in April 2010

• Supported widely by big players

• Twitter, Google, Yahoo! etc.

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?

3 Roles

• User (Resource Owner)

• You

• Consumer (Client)

• Twitter client on your iPhone

• Service Provider (Server)

• Twitter

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

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

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”

Step 0: Consumer Registrationhttp://developer.twitter.com

Step 0: Consumer Registration

• OAuth 1.0a Settings

• Consumer Key

• Consumer Secret

• Request Token URL

• Access Token URL

• Authorize URL

• Registered OAuth Callback URL

• Access Level

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

User Consumer Service ProviderDance Start!

Establish Request Token

Redirect with unauthorized Request Token

Redirect with authorized Request Token

Exchange it with Access Token

Approve Consumer access Authorized!

Step 1.1: Get Request Token

• Consumer requests to Service Provider

• POST to Request Token URL

• Include protocol parameters in Authorization header

OAuth Protocol Parameters

• realm

• The scope of access control

• oauth_consumer_key

• Identifier of Consumer

• oauth_signature, oauth_signature_method

• Used for request verification

• 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

Step 1.1: Get Request Token

• Service Provider responses to Consumer

• Include Request Token in response body

• application/x-www-form-urlencoded

• 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..

Step 1.2: Redirect to Service Provider

• Consumer let User redirect to Authorize URL

• Include Request Token in query string

Step 1.3: User Approval

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

• oauth_verifier

• Used when establishing Access Token

• Against session fixation attack

• Yeah, it’s a long history..

Step 1.5: Establish Access Token

• Consumer requests to Service Provider

• POST to Access Token URL

• Include protocol parameters in Authorization header

Step 1.5: Establish Access Token

• Service Provider responses to Consumer

• Include Access Token in response body

• application/x-www-form-urlencoded

• 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)

LOOK UP!GOAL IS ALMOST THERE!!

Step 2: Access to Protected ResourcesUser Consumer Service Provider

API Access

Revoke

API Accessxor Expired

Step 2: Access to Protected Resources

• Ex.) Twitter Status Update

• POST /statuses/update

• status=”Sorry Matz, I’m at OAuth Night tonight :p”

• lat=35.611953

• long=139.709272

Step 2: Access to Protected Resources

401 Unauthorized

• version_rejected

• parameter_absent

• parameter_rejected

• timestamp_refused

• nonce_used

• signature_method_rejected

• signature_invalid

• consumer_key_unknown

• consumer_key_rejected

• consumer_key_refused

• token_used

• token_expired

• token_revoked

• token_rejected

• verifier_invalid

• additional_authorization_required

• permission_unknown

• permission_denied

• user_refused

OAuth Errors

OAuth Signature

• Signature method

• PLAINTEXT

• No signing

• Use SSL/TLS instead

• HMAC-SHA1

• Use Consumer Secret & Access Token Secret

• RSA-SHA1

• Use Consumer’s RSA key pair

OAuth Signature• Signature Base String

• HTTP method (GET/POST/PUT/DELETE)

• Endpoint (http://server.example.com/user/nov)

• Parameter

• Protocol parameters (oauth_*)

• All other query/body parameters (only x-www-form-urlencoded)

• Sort by key

• ”Custom” percent encoding - tricky & buggy

OAuth Signature

POST&http%3A%2F%2Fapi.twitter.com%2Fstatuses%2Fupdate&lat%3D35.611953%26long%3D139.709272%26message%3DSorry%2520Matz%252C%2520I%2527m%2520at%2520OAuth%2520Night%2520tonight%2520%253Ap%26oauth_consumer_key%3D9djdj82h48djs9d2%26oauth_nonce%3D7d8f3e4a%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D137131201%26realm%3Dapi.twitter.com

1y4jjlXD7DC974H9cJVlXORwzt0%3D

HMAC-SHA1Consumer Secret + Access Token Secret

Signature Base String

Signature

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...

Ask Service Provider!!

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

Road to OAuth 2.0

OAuth 1.0 Known Issues• UX for non-web application

• No-browser environment (desktop apps)

• iPhone/Android apps? > @pofee

• Secret disclosure

• JS client/OpenSouce apps can’t keep Consumer Secret secret

• Complexity of Signature

• Use library!

• Scalability

OAuth 2.0 is solving those issues > @ritou

Questions?もちろん日本語で。

oauth 1.0

Technology

the how of oauth oauth hackathon – 4/26 @ six apart

oauth today -...

oauth test

the essential oauth primer: understanding oauth for securing...

oauth tutorial

incorporating oauth: how to integrate oauth into your mobile...

facebook & oauth

rfc 5849 - the oauth 1.0 protocol

category: informational issn: 2070-1721 the oauth … 5849...

using arcgis with oauth 2 - esri · before oauth •...

rfc5849 the oauth 1.0 protocol

oauth protokol -...

from a proposal to happy marriage...openid connect 2005 saml...

single sign-on security - hackmanit...3 history of single...

muhammad rizwan asghar - computer science · why oauth 2.0...

oauth 1.0 vs oauth 2.0 - principais diferenças e as razões...

the oauth 2.0 authorization protocol - cleesh.com · the...

oauthlint: an empirical study on oauth bugs in android...

the essential oauth primer: understanding oauth...

decentralised authorisation: oauth2€¦ · oauth history...