Re: [OAUTH-WG] Clarification of "client application consisting of multiple components"

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 <nov@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.selden@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 <eran@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:nov@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 <eran@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-bounces@ietf.org [mailto:oauth-bounces@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 <nov@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
>>
>>
>>
>