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
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
-~----------~----~----~----~------~----~------~--~---
