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