When the SP gets ready to direct the user back to the consumer after authorization, this secrete will be generated and stored in the callback URL. If the redirect is completely automated, the user will never see it. If the user has to manually enter it, then they must be careful not to share it with anyone except the consumer (probably a device / desktop application in this case). To add extra security the callback could use https to prevent man in the middle attacks and to verify the identity of the consumer.
On Sun, Apr 26, 2009 at 2:30 PM, pkeane <pjke...@gmail.com> wrote: > > > > On Apr 26, 2:04 pm, Josh Roesslein <jroessl...@gmail.com> wrote: > > Peter, no it does not verify it is the same user who requested the > request > > token. But it does verify the user did authenticate with the SP. > > The consumer can only exchange it's request token for an access token if > it > > receives the callback secrete from the user. > > But how did that user get that secret and how does the consumer > receive it? If the user had to personally remember it OR it was > stored somewhere that the user authenticated with (again, requring > authentication on the consumer) it is secure. Any other means allows > for (admittedly not easy) an attack. > > > The only way > > this value can be known is by authenticating with the SP. > > True, but the user can inadvertently pass it to the attacker. > > Sorry -- I don't mean to be difficult. just poking at ideas to see if > they fit my previous stated metric of verifyably matching the > u...@consumer to u...@sp. > > --peter > > > > > On Sun, Apr 26, 2009 at 1:42 PM, pkeane <pjke...@gmail.com> wrote: > > > > > On Apr 26, 12:48 am, Eran Hammer-Lahav <e...@hueniverse.com> wrote: > > > > Let's see if we can take a quick break from the discussion and get a > > > sense of where we are. Please answer the questions to follow. > > > > > > --- > > > > > > We have identified 2 solutions listed here: > > > > > >https://oauth.pbwiki.com/OAuth-Session-Fixation-Advisory > > > > > > * Signed Approval URLs > > > > > > This proposal breaks the protocol into two separate flows, one for > > > Consumers capable of launching a browser and accepting callbacks, and > > > another for those who can't. It requires a significant rewrite of the > > > specification because of the way the flow and signature are mixed > together > > > in the current Core 1.0 specification. > > > > > > * Signed Callback URLs > > > > > > This proposal makes the callback URL part of the signed request for > > > Request Token (which does not allow an attacker to manipulate it), and > adds > > > some unpredictable value to the callback redirection that is needed to > get > > > an Access Token. > > > > > > The spec changes include (see quick reference at the bottom): > > > > > > - Move the oauth_callback parameter from 6.2.1 to 6.1.1 > > > > - Add a new parameter to 6.2.3 which is needed to make 6.3.1 > > > > > > --- > > > > > > Open questions: > > > > > > 1. Am I missing a completely different alternative? If yes, please > create > > > a new wiki page and point to it (if you don't have access ask or email > it to > > > someone who does). > > > > > > 2. Given the simplicity of the Signed Callback URLs *specification > > > change*, I would like to instead of asking people which solution they > > > prefer, to ask people if they have a strong objection to using the > Signed > > > Callback URLs solution, and if so, to explain why? > > > > > I would just mention that this proposal (essentially making the > > > callback url immutable) limits the likelihood that the user who > > > authenticated w/ the SP is NOT user who requests an access token, it > > > does not actually verify that it is the same user. The only way I can > > > think of to do that is to store "state" in the user himself/herself > > > (as is always the case w/ passwords, biometrics, etc.). > > > > > In those cases that there is no callback, and the user has to actually > > > type in a pin/verifier (which was displayed to them when they > > > authenticated w/ SP) to request an access token, actual verification > > > IS taking place (state was stored on user) and our security hole is > > > fixed. > > > > > --peter > > > > > > 3. For the Signed Callback URLs solution, what to call the new > parameter > > > returned in 6.2.3? Suggestions so far included: > > > > > > - pin > > > > - verifier > > > > - chaperon > > > > - callback token > > > > - callback secret > > > > > > 4. And, should the new parameter be added to 6.3.1 (oauth_token + > > > oauth_something) or replace the value of the oauth_token parameter? > > > > > > The second option basically returns an authorized token which is used > > > with the existing secret from 6.1.2. The benefit of a new parameter is > it is > > > easier to follow the protocol. The benefit of reusing oauth_token to > make > > > 6.3.1 is that is keeps the signed request consistent with all other > signed > > > requests (no new parameters). > > > > > > EHL > > > > > > --- > > > > > > Quick Reference > > > > > > 6.1.1. Consumer Obtains a Request Token > > > > 6.1.2. Service Provider Issues an Unauthorized Request Token > > > > 6.2.1. Consumer Directs the User to the Service Provider > > > > 6.2.2. Service Provider Authenticates the User and Obtains Consent > > > > 6.2.3. Service Provider Directs the User Back to the Consumer > > > > 6.3.1. Consumer Requests an Access Token > > > > 6.3.2. Service Provider Grants an Access Token > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
