Thanks, I understand that the spec leaves it ambiguous, I read the long thread on multiple components single client ID.
I wanted to point out that this will be common despite this. Hopefully maybe to encourage FB to start an extension clarify this. Thanks for your help, I had overlooked using graph.facebook.com/app?access_token=your-token as a way to verify the client id. On Apr 5, 2012, at 6:19 PM, "matake, nov" <n...@matake.jp> wrote: > OAuth Core spec doesn't define those cases, so OAuth WG ML isn't the place to > report this issue though. > * how to handle an app which consists both client-side and server-side > components. > * how to use OAuth for login > > I already reported this issue to > * apple > * facebook > * foursquare > * pinterest > * yapp > > Not all of them are understanding this issue though.. > > 2012/4/6 matake, nov <n...@matake.jp> > Let me describe the details first. > > FB iOS SDK delegates the authorization step to the official FB iOS app via > "fbauth://authorize" custom schema URL. > (If the official app isn't available on the device, it just open > m.facebook.com authorization page using Safari) > > After the end-user approved the client access, FB server returns token and > code to the official FB app. > Then FB app passes token and code to the original app via the app's custom > schema (fb123456://authorize, numeric part is FB app_id of the app). > So if the app has its own server-side component, it should pass the code to > the server, not the access token. > (ref. > http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html) > > However, current FB iOS SDK just ignores the code and almost all developers > seems not using code. > Most apps are sending access tokens to their own server-side component. > (foursquare, pinterest, yapp etc.) > So the vulnerability John Bradley described before exists in many iOS app > using FB iOS SDK now. (maybe Android apps too) > http://www.thread-safe.com/2012/02/more-on-oauth-implicit-flow-application.html > > There are 2 solutions for this issue. > > First is modify FB iOS SDK and make code accessible from your app. > I'm already talking with FB guys about it, so I hope they change their code > by themselves. > For now, you can use my fork of FB SDK too. > https://github.com/nov/facebook-ios-sdk > > If 1st one is hard for you (because you cannot remove legacy version of your > app from the users device etc), you can also use FB Graph API endpoint to > verify access token audience. > Send a GET request to graph.facebook.com/app?access_token=your-token, then > you'll get application info to which the token is established. > > 2012/4/6 Kristofor Selden <kris.sel...@gmail.com> > How do I deal with this? > https://twitter.com/#!/nov/status/187895781011890176 > > My assumption is after getting the user to authorize the client via the FB > SDK on the iPhone app, one would send the authorization code (not the access > token) back to the server via HTTPS where it would just get a new token using > the client id+secret and the authorization code, given that the server client > id is the same as iPhone apps client id. > > Is this correct? > > With mobile apps, having multiple components use the same client id is going > to be common regardless if that is less than ideal. It is common to have a > native mobile client component paired with a server component both using FB > social graph using the same client_id. > > For many startups FB won the social graph war and we just want to leverage > that and focus on our offerings. > > Thanks, > Kris > > On Mar 11, 2012, at 10:43 AM, nov matake wrote: > >> I understood. >> Thanks. >> >> -- >> nov >> >> On Mar 12, 2012, at 2:30 AM, Eran Hammer <e...@hueniverse.com> wrote: >> >>> That use case was removed from the specification. Either way, it is up to >>> the authorization server to decide which registration options to offer the >>> client if they make such a grant type available in the future, and how it >>> will apply the security policies. IOW, those proposing such an extension in >>> the future will have to figure out how this should be handled. >>> >>> EH >>> >>>> -----Original Message----- >>>> From: nov matake [mailto:n...@matake.jp] >>>> Sent: Sunday, March 11, 2012 10:21 AM >>>> To: Eran Hammer >>>> Cc: nov matake; oauth@ietf.org WG >>>> Subject: Re: [OAUTH-WG] Clarification of "client application consisting of >>>> multiple components" >>>> >>>> So what is the usecase of response_type=token%20code ? >>>> I thought, in that usecase, token was for the client's client-side >>>> component, >>>> code was for the client's server-side component, and both of them have the >>>> same client_id. >>>> >>>> -- >>>> nov >>>> >>>> On Mar 12, 2012, at 12:57 AM, Eran Hammer <e...@hueniverse.com> wrote: >>>> >>>>> If you have two components each with different security profile, you must >>>> assign each a different client_id. Otherwise, there is no way to enforce >>>> the >>>> rest of the spec's security requirements. >>>>> >>>>> EH >>>>> >>>>>> -----Original Message----- >>>>>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On >>>>>> Behalf Of nov matake >>>>>> Sent: Sunday, March 11, 2012 8:25 AM >>>>>> To: oauth@ietf.org WG >>>>>> Subject: [OAUTH-WG] Clarification of "client application consisting >>>>>> of multiple components" >>>>>> >>>>>> Hi, >>>>>> >>>>>> I just found this sentence in the latest draft. >>>>>> >>>>>> Does it mean "an application consisting of server-side and >>>>>> client-side component (eg. foursquare iPhone app) MUST have separate >>>>>> client_id for each component" ? >>>>>> Or can I image something like Facebook is doing right now? (register >>>>>> each component for a single client_id separately) >>>>>> >>>>>> == >>>>>> A client application consisting of multiple components, each with its >>>>>> own client type (e.g. a distributed client with both a confidential >>>>>> server-based component and a public browser-based component), MUST >>>>>> register each component separately as a different client to ensure >>>>>> proper handling by the authorization server. The authorization >>>>>> server MAY provider tools to manage such complex clients through a >>>> single administration interface. >>>>>> == >>>>>> >>>>>> -- >>>>>> nov <n...@matake.jp> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
