On Apr 24, 3:23 pm, joshthecoder <[email protected]> wrote:
> Actually after some more thought I have come up with this new
> revision:
>
> 1. User visits authorization URL that directs them to the service
> provider's site.
> This link can be provided by the consumer.
> Example:http://www.pictureland.com/oauth/authenticate?consumer=printit.com
> 2. User authenticates with service provider.
> 3. User authorizes access to the consumer. Optionally this page can
> also be used
> for setting other restrictions (ex. lifetime of token, resource
> access rights, etc)
Am I correct in characterizing #2 & #3 as collapsing the OAuth A & B
steps into one interaction. Or perhaps more accurately, eliminating
step A (getting a request token that will need to be authorized) and
going right to B & C?
--peter
> 4. Service provider generates access token (only usable by the
> consumer)
> 5. User redirected to consumer URL with token attached.
> Example:http://www.printit.com/oauth/regiser?token=12345
> 6. Consumer can optionally have user login and bind token with the
> account
> OR
> Create session cookie stored in browser and token is bound to this
> session.
> 7. Consumer can now use token to access protected resources.
>
> This way the service provider does not have to manage consumer account
> <--> service account relationships.
> It simply generates a token for a specific consumer and then redirects
> user with token to consumer provided URL.
> It is now up to the service provider to bind this token to an account
> or session.
>
> To prevent man in the middle attack of stealing this token, this
> callback URL should use SSL.
>
> On Apr 24, 3:07 pm, joshthecoder <[email protected]> wrote:
>
> > How about this idea...
>
> > Instead of the Request token --> Redirect to Service provider w/ token
> > process how about just redirecting
> > straight to the service provider with just the consumer ID in the
> > URL.
>
> > 1. User visits Consumer site and can optionally register an account.
> > 2. Consumer registers account or pin with Service provider by making
> > request.
> > 3. User visits the generated URL from the consumer
> > (ex.http://www.pictureland.com/oauth?consumer_id=<consumer ID>)
> > 4. User authenticates with Service provider
> > 5. User directed to consumer authorization page on Service provider
> > where they must enter in the username or PIN for the consumer (more on
> > PINs later)
> > 6. User enters in username or pin # and clicks authorize (optionally
> > can also select access restrictions for the consumer on this page
> > also)
> > 7. Service provider validates username / pin and if valid calls
> > consumer callback URL with access token included
> > 8. User redirected to consumer
> > 9. Consumer can now use access token
>
> > Pins: Allow for authorizing consumer access w/o having to create an
> > account. Pin is generated by consumer and then registered with service
> > provider.
> > User must then copy and paste pin into authorization page on
> > service provider.
>
> > Here is a diagram displaying this process (using username
> > method):http://i42.tinypic.com/2uqlimd.png
>
> > So what is do you think?
>
> > On Apr 24, 2:43 pm, Luca Mearelli <[email protected]> wrote:
>
> > > On Fri, Apr 24, 2009 at 8:03 PM, Brian Eaton <[email protected]> wrote:
>
> > > > No, we haven't, and in fact we can't with the protocol as it stands
> > > > today. Please go read Eran's blog post explaining the attack:
>
> > > >http://www.hueniverse.com/hueniverse/2009/04/explaining-the-oauth-ses...
>
> > > We haven't solved it completely (as in *made impossible*), but those
> > > minimal additions to the protocol reduce a lot the available attack
> > > window. I think that security work should at least seek improving
> > > un-feasibility of an attack vector under given constraints.
>
> > > I read Eran's article before sending the first email of the long
> > > thread, and I'm a bit lost in the whole discussion now, but I'd still
> > > like to know if what I said there missed the point e.g. with regards
> > > to the fact that the SP cannot safely pass information, like the
> > > "unpredictable callback parameter", back to the consumer over the
> > > redirect if the callback URL is not verified ...
>
> > > I hope this doesn't sound stupid or pedantic (I'm just trying to
> > > understand)
>
> > > Luca
>
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
