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
