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

"matake, nov" <nov@matake.jp> Fri, 06 April 2012 01:19 UTC

Return-Path: <nov@matake.jp>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B98921F8736 for <oauth@ietfa.amsl.com>; Thu, 5 Apr 2012 18:19:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.376
X-Spam-Level:
X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YDM3ZNMDfcRl for <oauth@ietfa.amsl.com>; Thu, 5 Apr 2012 18:19:01 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8C70F21F86E8 for <oauth@ietf.org>; Thu, 5 Apr 2012 18:19:01 -0700 (PDT)
Received: by yenm5 with SMTP id m5so1226572yen.31 for <oauth@ietf.org>; Thu, 05 Apr 2012 18:19:01 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=FDgnV+0vwIruxMHlk846VyIqDqeMzyiJ/Va5/azov2g=; b=l/8hGw+hNDR2o+OjsWSy5cn6zn0a9f7xmmhj3BKrtxqGf01DZqZFNCyrralC4+NeNU CGsScMV90+os9+OmOYK72Ncj96OiO2/b00DlyyjlbXsUtUT8UfHMm36LNnzlEgCt1I2M 9lG5ayMFcF/F1qKruAhgj0xp1BpdW90m5hhsgVD3/laHhgu6fzLEmzt0JezZY0cjzxhc QVRERqrY+8D7IhogvedWkPxfNOHVoSW1qpBwnMZBzLpBKU8nCypM9Uvle+5TKgx8sLDs jyjW8AA4kIPb2yfhifto/2sPr2foqr3TQPGRrKNchwlT/NfaMlt5EBFcxf4K0PjyTSk6 JykA==
MIME-Version: 1.0
Received: by 10.101.138.33 with SMTP id q33mr1508995ann.76.1333675141130; Thu, 05 Apr 2012 18:19:01 -0700 (PDT)
Received: by 10.220.0.70 with HTTP; Thu, 5 Apr 2012 18:19:01 -0700 (PDT)
X-Originating-IP: [124.32.97.98]
In-Reply-To: <CAHHppZ-S0P97_kK68Ug5hvse-jSNiwiU6w00d=k5CsKDDdvjpg@mail.gmail.com>
References: <62D85564-7961-4AB6-B1FA-B2DD75A4C74B@matake.jp> <90C41DD21FB7C64BB94121FBBC2E723453AFF08605@P3PW5EX1MB01.EX1.SECURESERVER.NET> <C129DBDE-09EE-42F9-8530-5D777A3457DE@matake.jp> <90C41DD21FB7C64BB94121FBBC2E723453AFF08609@P3PW5EX1MB01.EX1.SECURESERVER.NET> <038CA61F-9DB3-45BC-8DEF-85738F50EA97@matake.jp> <5DBF7969-23BB-4131-BE1D-B2B27F7C030D@gmail.com> <CAHHppZ-S0P97_kK68Ug5hvse-jSNiwiU6w00d=k5CsKDDdvjpg@mail.gmail.com>
Date: Fri, 6 Apr 2012 10:19:01 +0900
Message-ID: <CAHHppZ9eGTF8KMiXxMNu5_ogeGW3ZkwOVMK_kWDfwEQaPZBiAg@mail.gmail.com>
From: "matake, nov" <nov@matake.jp>
To: Kristofor Selden <kris.selden@gmail.com>
Content-Type: multipart/alternative; boundary=0016e68ee348086a2804bcf871c7
X-Gm-Message-State: ALoCoQlQjMlR17SOMNyOrvXgw1XZen1AQoAqbgGGmC3Z8Fc865yre4wLCxjbdKpTp+P4Fy9ZXQBL
Cc: "oauth@ietf.org WG" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Clarification of "client application consisting of multiple components"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Apr 2012 01:19:03 -0000

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