On Apr 24, 4:54 pm, pkeane <[email protected]> wrote:
> On Apr 24, 2:59 pm, Dossy Shiobara <[email protected]> wrote:
>
>
>
> > On 4/24/09 2:42 PM, pkeane wrote:
>
> > > I'm pretty sure it does. Let me see if I can sketch out the scenario:
>
> > > 1. user goes to photoeditor.com to edit some photos. photoeditor.com
> > > gives me a menu of "partners" that I can use photos from: Flickr,
> > > Picasa, etc.
> > > 2. I select Flickr and I am immediately sent to to sign into my
> > > account (using my Flick user/pass).
> > > 3. Now instead of sending me back to photoeditor.com, I am forwarded
> > > to the Flickr OAuth page where it asks "do you want to continue on to
> > > photoeditor.com"?
> > > 4. I click "yes," and I am forwarded back to photoeditor.com fully
> > > able to edit my Flickr photos.
>
> > > Is that possible? I'm not sure it matters what order things are done
> > > on at the SP -- the basic idea is that the A& B steps are collapsed
> > > down into*one* step, all of which happens on the SP.
>
> > > Apologizes if it is an obviously flawed idea -- just trying to get my
> > > head around it.
>
> > OK, let me describe a hypothetical narrative description of an user
> > experience:
>
> > Bob has a Gmail account and a Flickr account. In this narrative, Gmail
> > is the Consumer and Flickr is the Provider.
>
> > ====
>
> > Worst-case user experience scenario:
>
> > Bob logs into Gmail and composes an email. He uses the "attach a
> > picture from Flickr" feature.
>
> > 1) Gmail links Bob to Flickr's OAuth "identity" endpoint.
>
> > 2) Since Bob hasn't authenticated to Flickr yet, Flickr displays its
> > authentication dialog and verifies Bob's identity.
>
> > 3) Flickr then sends Bob back to Gmail's OAuth identity callback,
> > passing a one-time-use identity token.
>
> > 4) Gmail uses this token along with its consumer key and secret to do a
> > server-to-server request to Flickr's OAuth request token endpoint, which
> > returns a one-time-use request token and corresponding secret.
>
> > (At this point, the identity token is no longer valid or usable.)
>
> > 5) Gmail now sends Bob to Flickr's OAuth authorization endpoint, and
> > since Bob hasn't authorized Gmail to Flickr, presents him an
> > authorization dialog.
>
> > 6) Bob authorizes Gmail and Flickr sends him back to Gmail's
> > authorization callback.
>
> > 7) Gmail then performs a server-to-server request upgrading the request
> > token to an access token.
>
> > (At this point, the request token is no longer valid or usable.)
>
> > 8) Gmail proceeds to use Flickr's API using Bob's authorized access token.
>
> > ====
>
> > Here's what a best-case user experience scenario might look like, where
> > Bob hasn't yet authorized Gmail but has already logged into Flickr
> > previously in the same browser session:
>
> > Bob logs into Gmail and composes an email. He uses the "attach a
> > picture from Flickr" feature.
>
> > 1) Gmail links Bob to Flickr's OAuth "identity" endpoint.
>
> > 2) Since Flickr has already authenticated Bob's session previously,
> > there's no need for the authentication dialog. Flickr simply bounces
> > Bob back to Gmail's identity callback with the one-time-use identity token.
>
> > 4) Gmail uses this token along with its consumer key and secret to do a
> > server-to-server request to Flickr's OAuth request token endpoint, which
> > returns a one-time-use request token and corresponding secret.
>
> > (At this point, the identity token is no longer valid or usable.)
>
> > 5) Gmail now sends Bob to Flickr's OAuth authorization endpoint, and
> > since Bob hasn't authorized Gmail to Flickr, presents him an
> > authorization dialog.
>
> > 6) Bob authorizes Gmail and Flickr sends him back to Gmail's
> > authorization callback.
>
> > 7) Gmail then performs a server-to-server request upgrading the request
> > token to an access token.
>
> > (At this point, the request token is no longer valid or usable.)
>
> > 8) Gmail proceeds to use Flickr's API using Bob's authorized access token.
>
> > ====
>
> > Suppose Gmail doesn't want to persist these access tokens for whatever
> > reason. Here's what an example scenario might look like, where Bob has
> > previously authorized Gmail and is already logged into Flickr in the
> > same browser session:
>
> > Bob logs into Gmail and composes an email. He uses the "attach a
> > picture from Flickr" feature.
>
> > 1) Gmail links Bob to Flickr's OAuth "identity" endpoint.
>
> > 2) Since Flickr has already authenticated Bob's session previously,
> > there's no need for the authentication dialog. Flickr simply bounces
> > Bob back to Gmail's identity callback with the one-time-use identity token.
>
> > 4) Gmail uses this token along with its consumer key and secret to do a
> > server-to-server request to Flickr's OAuth request token endpoint, which
> > returns a one-time-use request token and corresponding secret.
>
> > (At this point, the identity token is no longer valid or usable.)
>
> > 5) Gmail now sends Bob to Flickr's OAuth authorization endpoint, and
> > Flickr knows that Bob has previously authorized Gmail to Flickr, sends
> > him immediately back to Gmail's authorization callback.
>
> > 6) Gmail then performs a server-to-server request upgrading the request
> > token to an access token.
>
> > (At this point, the request token is no longer valid or usable.)
>
> > 7) Gmail proceeds to use Flickr's API using Bob's authorized access token.
>
> > ====
>
> > Any questions?
>
> If I am following correctly, this should work. But there are a few
> drawbacks I see. It is fairly dramatically different from the way
> OAuth works now for all parties: user, consumer, provider. It also
> seems quite complex (maybe I am being dense :) to me, a hallmark of a
> good security scheme is simplicity and clarity to the extent
> possible. I'd like to see a procedure that can scale down as well as
> up -- meaning that the provider can offer a simpler experience when
> the situation allows for somewhat less "assured" security. My concern
> about too much complexity is the possibilty that bad implementations
> sprout up. Also -- are server-to-server requests on the table? Those
sorry -- dumb comment. OAuth currently uses server-to-server
requests.
--peter
> are not in the current spec and I didn't know if they had already been
> consider in earlier iterations of OAuth (I've not read back over the
> list, which I ought to do...).
>
> --peter
>
>
>
> > --
> > Dossy Shiobara | [email protected] |http://dossy.org/
> > Panoptic Computer Network |http://panoptic.com/
> > "He realized the fastest way to change is to laugh at your own
> > folly -- then you can let go and quickly move on." (p. 70)
>
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
