Yes it eliminates the request token and basically skips to step D. I don't
really see the need for request tokens.
We can just direct the user to the service provider's URL for the consumer,
authenticate, and return the access token in the callback.
in the callback that is given when the consumer was registered. Could also
support dynamically setting callback by including
it in the authorization URL and signing it.
The flow would be:
User visits consumer --> Consumer directs user to authorization URL --> User
authenticates with service provider --> Grant access to consumer -->
Directed back to consumer with access token
By not having request tokens, an attacker can't really get into the flow.
There are two issues:
1. Service providers and Users must watch out for bad consumers that
register with the service provider. This can be avoided by
proper screening by the service provider (make sure the consumer is
legit) and the User knowing the consumer they are granting access.
Example:
- Attacker sends user this link:
http://www.serviceprovider.com/oauth/authorize?consumer=badconsumer.com
- User authenticates and grants access
- Directed to bad consumer site with access key
- Bad consumer steals private data with access key
To fix attack:
- Delete consumer account on service provider
- Invalidate all access tokens generated by this consumer account
2. The token can be stolen by a man in the middle attack during the
callback. This can be avoided by using https.
On Fri, Apr 24, 2009 at 4:59 PM, pkeane <[email protected]> wrote:
>
>
>
> 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
-~----------~----~----~----~------~----~------~--~---
