First we would like to congratulate OAuth community on winning
European Identity Award for the category “Best new or improved
standard” 
http://blog.oauth.net/2009/05/11/oauth-wins-award-at-european-identity-conference/.

Great industry adoption and recognition!

Since the session fixation vulnerability with OAuth Spec 1.0 was
identified in Apr,  great/unprecedented response from the OAuth
community, including several solutions proposed and published
http://wiki.oauth.net/Signed-Callback-URLs
http://wiki.oauth.net/Signed-Approval-URLs

The Signed Callback URLs with verification code has been proposed in
Core Spec 1.0 Rev A (with the latest Draft 3)
http://oauth.googlecode.com/svn/spec/core/1.0a/drafts/3/oauth-core-1_0a.html.

But as discussed extensively earlier
http://groups.google.com/group/oauth/browse_thread/thread/610f8222ddef206a/22796338336ea430session,
session fixation issue could still be exposed if with bad consumer
implementation of earlier binding unauthorized Request Token with
userid on consumer side.

Built upon the Signed Callback URLs approach as in 1.0 Rev A, we
propose to replace Request Token with a different Approved Token after
approval by user, if with callback to consumer.  Since Approved Token
is different from Request Token,
* it seems Approved Token will not be linked back to bad userid even
with bad early binding on consumer side
* and verification code would no longer be necessary

Would really appreciate the feedback to see if this is a viable
approach.
If so, any down side comparing to verification code in Core Spec 1.0
Rev A (Draft 3)?

Thanks in advance,

Jeff


Proposed Changes to Core Spec 1.0
==========================
Changes to OAuth 1.0 are marked with ===>.
1. Consumer requests request token. Included in the request:
oauth_consumer_key: the Consumer key
oauth_signature_method: the signature method used
oauth_signature: the signature
oauth_timestamp: as defined in OAuth spec
oauth_nonce: as defined in OAuth spec
oauth_version: OPTIONAL. If present, MUST be 1.0. If absent, MUST be
assumed to be 1.0
===> oauth_callback: REQUIRED. Absolute URL to which to return the
user after authorization or oob.

2. Service Provider issues an Unauthorized Request Token. The SP MUST
associate the callback URL sent in Step 1 with the request token it
issues. It can do that either in local storage, or by encoding the
callback URL in the request token in an unforgeable way. Response
includes:
oauth_token: the request token
oauth_token_secret: the request token secret
===> oauth_callback_confirmed MUST be present and set to true. The
Consumer MAY use this to confirm that the Service Provider received
the callback value.

3. Consumer sees that SP supports oauth_callback URL by checking for
oauth_callback_accepted parameter. Consumer Directs User to the
Service Provider. Parameters include:
oauth_token: OPTIONAL
===> oauth_callback: REMOVED

4. Service Provider Authenticates User and Obtains Consent
===> After approval by user, generate Approved Token if oauth_callback!
=oob, which should be different from Request Token.

5. Service Provider Redirects the User Back to Consumer. This only
happens if the Consumer callback sent in Step 1 is not oob. Included
in the request:
===> oauth_token: REQUIRED. if oauth_callback=oob, request token. If
oauth_callback!=oob, Approved Token (with different value), not
Request Token.

6. Obtaining an Access Token. Included in the request:
oauth_consumer_key: the consumer key
===> oauth_token: the token obtained in Step 5, not request token
obtained in Step 2.
oauth_signature_method: signature method
oauth_signature: the signature
oauth_timestamp: as in the OAuth spec
oauth_nonce: as in the OAuth spec
oauth_version: OPTIONAL. If present, MUST be 1.0. If absent, MUST be
assumed to be 1.0

7. Service Provider Grants an Access Token. Included in the request:
oauth_token: the access token
oauth_token_secret: the access token secret

Proposed Changes to Core Spec 1.0 Rev A Draft 3
=====================================
Changes to OAuth 1.0 Rev A Draft 3 are marked with ===>.
1. Consumer requests request token. Included in the request:
oauth_consumer_key: the Consumer key
oauth_signature_method: the signature method used
oauth_signature: the signature
oauth_timestamp: as defined in OAuth spec
oauth_nonce: as defined in OAuth spec
oauth_version: OPTIONAL. If present, MUST be 1.0. If absent, MUST be
assumed to be 1.0
oauth_callback: REQUIRED. Absolute URL to which to return the user
after authorization or oob.

2. Service Provider issues an Unauthorized Request Token. The SP MUST
associate the callback URL sent in Step 1 with the request token it
issues. It can do that either in local storage, or by encoding the
callback URL in the request token in an unforgeable way. Response
includes:
oauth_token: the request token
oauth_token_secret: the request token secret
oauth_callback_confirmed MUST be present and set to true. The Consumer
MAY use this to confirm that the Service Provider received the
callback value.

3. Consumer sees that SP supports oauth_callback URL by checking for
oauth_callback_accepted parameter. Consumer Directs User to the
Service Provider. Parameters include:
oauth_token: OPTIONAL

4. Service Provider Authenticates User and Obtains Consent
===> After approval by user, generate Approved Token , which should be
different from Request Token.

5. Service Provider Redirects the User Back to Consumer. This only
happens if  callback sent in Step 1 is not oob. Included in the
request:
===> oauth_token: REQUIRED. if oauth_callback=oob, Request Token. If
oauth_callback!=oob, Approved Token (with different value), not
Request Token".
===> verfication_code: REMOVED

6. Obtaining an Access Token. Included in the request:
oauth_consumer_key: the consumer key
===> oauth_token: the token obtained in Step 5, not request token
obtained in Step 2.
oauth_signature_method: signature method
oauth_signature: the signature
oauth_timestamp: as in the OAuth spec
oauth_nonce: as in the OAuth spec
oauth_version: OPTIONAL. If present, MUST be 1.0. If absent, MUST be
assumed to be 1.0
verfication_code: REMOVED

7. Service Provider Grants an Access Token. Included in the request:
oauth_token: the access token
oauth_token_secret: the access token secret

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [email protected]
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to