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

"matake, nov" <nov@matake.jp> Fri, 06 April 2012 01:09 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 8786921F8618 for <oauth@ietfa.amsl.com>; Thu, 5 Apr 2012 18:09:00 -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 VP5Bw-Q8g4Nf for <oauth@ietfa.amsl.com>; Thu, 5 Apr 2012 18:08:59 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0F61021F8617 for <oauth@ietf.org>; Thu, 5 Apr 2012 18:08:58 -0700 (PDT)
Received: by ghbg16 with SMTP id g16so1231359ghb.31 for <oauth@ietf.org>; Thu, 05 Apr 2012 18:08:58 -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=vmNvd3Cxu1pxEcNpKzCshz3ImYVJg4E3XlT11+c6KBE=; b=hoQd0Px/kQFttUMR0mLL0d8ZcJvfvBwjIS5+ujl+uGSTqB2BVKNCiTb6M4tmJeJise swUhsq2dbl/0muM96hpKl/w4shI0t43YsGP900Wu8t1SMou92GqAKDKb73tDE8Jryt25 1ARGalelOBKRpeLPfL7sUlDNNNa9tJqBOAZEhF6tBs+oaSyMYbJUNavgGOQmVCjg30yz r4ZJgnmNWYlXYnyMEQV4EqKm2IhZwpk9tmiHXiEHBwg2D4/rf5GHHgYZPHXuq/34qsgp kFc9RCQbZqBztU4P/6tfZH+UpoTSc9Np0AwtDQ2oKH/nmLsdBOooVFKfgXINbQzm2ozJ R8Mg==
MIME-Version: 1.0
Received: by 10.236.197.66 with SMTP id s42mr4794025yhn.69.1333674538552; Thu, 05 Apr 2012 18:08:58 -0700 (PDT)
Received: by 10.220.0.70 with HTTP; Thu, 5 Apr 2012 18:08:58 -0700 (PDT)
X-Originating-IP: [124.32.97.98]
In-Reply-To: <5DBF7969-23BB-4131-BE1D-B2B27F7C030D@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>
Date: Fri, 6 Apr 2012 10:08:58 +0900
Message-ID: <CAHHppZ-S0P97_kK68Ug5hvse-jSNiwiU6w00d=k5CsKDDdvjpg@mail.gmail.com>
From: "matake, nov" <nov@matake.jp>
To: Kristofor Selden <kris.selden@gmail.com>
Content-Type: multipart/alternative; boundary=20cf303f6d681dcf2504bcf84d27
X-Gm-Message-State: ALoCoQnMcW9JRJKEWlDqPSdmEGOiw9CBnqT6Hs3fE0pJZwjdFuvD1EMKKqUBRHYl/aUWxANYfc8o
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:09:00 -0000

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