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

Kristofor Selden <kris.selden@gmail.com> Thu, 05 April 2012 19:38 UTC

Return-Path: <kris.selden@gmail.com>
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 0996421F8647 for <oauth@ietfa.amsl.com>; Thu, 5 Apr 2012 12:38:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.998
X-Spam-Level:
X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 2qLD31RnD5mF for <oauth@ietfa.amsl.com>; Thu, 5 Apr 2012 12:38:44 -0700 (PDT)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id F2F5221F8645 for <oauth@ietf.org>; Thu, 5 Apr 2012 12:38:43 -0700 (PDT)
Received: by pbbrq13 with SMTP id rq13so1783481pbb.31 for <oauth@ietf.org>; Thu, 05 Apr 2012 12:38:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=Oya+TGr4lAXrLRCX11tJjaQIn5+s+4LtuS9Hkl+6qMk=; b=S2SdXLlJCmgaxOQ/tNHg0Ld7BAywvI4NJGNWSghi89xRQuVuh+M3dFaqaJwnGHwrUH 0/L4OD5kGgIGBeZa+9LvRQFPafyhbndRyCJdX9fS/7CaKN1pcm7k46uSWy7kyFC9MEde GEBh7guwe3mgMe3uIFXNxWxB2UQ+r0gytm1+xY2VFdNZ+wpdG0tt9zqKhW7MneTwlBTZ ywCGQKfWyOluNLCYVPBCoz1tvcklVGXiHb7k06VVpJe6xFy5DC/CyZgnBM88xx1loiUT X4VMW7b9S9n1R+2/J2tC08UchAnG2rKonxXSRTvDcsZJyRAuhM9cGQWGr7VqXgIJSaZt Nh5g==
Received: by 10.68.196.138 with SMTP id im10mr9095767pbc.156.1333654723517; Thu, 05 Apr 2012 12:38:43 -0700 (PDT)
Received: from [192.168.169.6] (c-98-247-241-51.hsd1.wa.comcast.net. [98.247.241.51]) by mx.google.com with ESMTPS id r6sm4044159pbl.24.2012.04.05.12.38.41 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Apr 2012 12:38:42 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/alternative; boundary="Apple-Mail=_67564068-15FF-4A10-93DF-3B8E3C3BB3B0"
From: Kristofor Selden <kris.selden@gmail.com>
In-Reply-To: <038CA61F-9DB3-45BC-8DEF-85738F50EA97@matake.jp>
Date: Thu, 5 Apr 2012 12:38:36 -0700
Message-Id: <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>
To: nov matake <nov@matake.jp>
X-Mailer: Apple Mail (2.1257)
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: Thu, 05 Apr 2012 19:38:45 -0000

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
>