On Apr 26, 12:48 am, Eran Hammer-Lahav <[email protected]> wrote:
> Let's see if we can take a quick break from the discussion and get a sense of
> where we are. Please answer the questions to follow.
>
> ---
>
> We have identified 2 solutions listed here:
>
> https://oauth.pbwiki.com/OAuth-Session-Fixation-Advisory
>
> * Signed Approval URLs
>
> This proposal breaks the protocol into two separate flows, one for Consumers
> capable of launching a browser and accepting callbacks, and another for those
> who can't. It requires a significant rewrite of the specification because of
> the way the flow and signature are mixed together in the current Core 1.0
> specification.
>
> * Signed Callback URLs
>
> This proposal makes the callback URL part of the signed request for Request
> Token (which does not allow an attacker to manipulate it), and adds some
> unpredictable value to the callback redirection that is needed to get an
> Access Token.
>
> The spec changes include (see quick reference at the bottom):
>
> - Move the oauth_callback parameter from 6.2.1 to 6.1.1
> - Add a new parameter to 6.2.3 which is needed to make 6.3.1
>
> ---
>
> Open questions:
>
> 1. Am I missing a completely different alternative? If yes, please create a
> new wiki page and point to it (if you don't have access ask or email it to
> someone who does).
>
> 2. Given the simplicity of the Signed Callback URLs *specification change*, I
> would like to instead of asking people which solution they prefer, to ask
> people if they have a strong objection to using the Signed Callback URLs
> solution, and if so, to explain why?
I would just mention that this proposal (essentially making the
callback url immutable) limits the likelihood that the user who
authenticated w/ the SP is NOT user who requests an access token, it
does not actually verify that it is the same user. The only way I can
think of to do that is to store "state" in the user himself/herself
(as is always the case w/ passwords, biometrics, etc.).
In those cases that there is no callback, and the user has to actually
type in a pin/verifier (which was displayed to them when they
authenticated w/ SP) to request an access token, actual verification
IS taking place (state was stored on user) and our security hole is
fixed.
--peter
>
> 3. For the Signed Callback URLs solution, what to call the new parameter
> returned in 6.2.3? Suggestions so far included:
>
> - pin
> - verifier
> - chaperon
> - callback token
> - callback secret
>
> 4. And, should the new parameter be added to 6.3.1 (oauth_token +
> oauth_something) or replace the value of the oauth_token parameter?
>
> The second option basically returns an authorized token which is used with
> the existing secret from 6.1.2. The benefit of a new parameter is it is
> easier to follow the protocol. The benefit of reusing oauth_token to make
> 6.3.1 is that is keeps the signed request consistent with all other signed
> requests (no new parameters).
>
> EHL
>
> ---
>
> Quick Reference
>
> 6.1.1. Consumer Obtains a Request Token
> 6.1.2. Service Provider Issues an Unauthorized Request Token
> 6.2.1. Consumer Directs the User to the Service Provider
> 6.2.2. Service Provider Authenticates the User and Obtains Consent
> 6.2.3. Service Provider Directs the User Back to the Consumer
> 6.3.1. Consumer Requests an Access Token
> 6.3.2. Service Provider Grants an Access Token
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
