Re: [OAUTH-WG] Sharing a client_id: is it good or bad ?

John Bradley <ve7jtb@ve7jtb.com> Wed, 04 November 2015 22:20 UTC

Return-Path: <ve7jtb@ve7jtb.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C09451B348E for <oauth@ietfa.amsl.com>; Wed, 4 Nov 2015 14:20:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9RXfvmcYJiFX for <oauth@ietfa.amsl.com>; Wed, 4 Nov 2015 14:20:47 -0800 (PST)
Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 045701A702B for <oauth@ietf.org>; Wed, 4 Nov 2015 14:20:46 -0800 (PST)
Received: by pasz6 with SMTP id z6so67142150pas.2 for <oauth@ietf.org>; Wed, 04 Nov 2015 14:20:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb_com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=j9FEvTxtbVMU0RwLPgOwQZv8dQrpGe3EzsPcjWRtco4=; b=kDklXq9PT61pfPp3roEj3Qe4DCEorvlyRNpbm/XHTajV4veDTWE1LmQqns8PDYrjhi DRJd2jurbzQWYjy8ZHV33Ov+cYfKC/SrYj8W/rS/btN8eFefoFj00uAchRn4wqCx3Z19 gCevdkMtlXRjh1v2MBM+2xPyqpg7mEtGdgKtbTEtXAKS/zIHd+3aF8XiMfzBEjG9Ceyj NIaTyAMy2RONu5z7seXOA7yU4LeoqlwQGyx9WeYlG6zJvQ7i2awXRTiEXUD+Ha3lTe1T 3FnFxLuHTip0ZuKBBChCFEJf6QgdMS4GfwF0Dh/VPZbyJYyxgo7eh5gpsbmbluhXGRGS fPQg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=j9FEvTxtbVMU0RwLPgOwQZv8dQrpGe3EzsPcjWRtco4=; b=TSIE7FYTWopYTwCshcP5ZAsjXQYtBLMCVB3qqZiFXDrxzrvz74Gn3XLBh0zkIgwGRs p0bzuJTGwM5Ot0+zKOy4Fnzm9sbCrr4WWchfX+9lMfavnkr5/J4K0OZM54xWlC9wOG5K 10hSJdTlyAO35ZJrINUQCpq3Cf2vy6HR98DDOalSNIrymhPEx4hmFc8fYcz+BdjsAe87 HpzVBAb29ufPkO74BLuIUZWj5aLNifTr6rO9fI1KU0Hevh9mOcuj/uTdLbBEbAO9TIxW hO0qwWTppYYjKoliOAk0ORkS51FE5HGN+htdBglV3DpCWrcwLiadZMb2sUMO1i/EqogI O2KA==
X-Gm-Message-State: ALoCoQlNrVYbKcJW8/0UfUkA36N1sZXo7W1BUyE4bhGLpKBxyf758LvWBK1kxklQ5jJTlcluRDXS
X-Received: by 10.68.132.71 with SMTP id os7mr4927588pbb.125.1446675646430; Wed, 04 Nov 2015 14:20:46 -0800 (PST)
Received: from t20010c400000308021f8199b7e9235ac.v6.meeting.ietf94.jp (t20010c400000308021f8199b7e9235ac.v6.meeting.ietf94.jp. [2001:c40:0:3080:21f8:199b:7e92:35ac]) by smtp.gmail.com with ESMTPSA id ou3sm3920293pbb.44.2015.11.04.14.20.45 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Nov 2015 14:20:45 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <563A2BCC.6030801@gmail.com>
Date: Thu, 5 Nov 2015 07:20:42 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <77B2A3DD-3C0F-49EB-AD7F-9C4DAA6542AE@ve7jtb.com>
References: <CAH_M0wuMq-TANrCBPRJ7LmtRfCmQdBpnitY=0ws6h4O82GrCuA@mail.gmail.com> <6A84AF37-C6FC-41DD-99D6-32A8DDD7A18A@mit.edu> <CAAP42hCV8ibpERocOBRPXccWO3K05=E8frtcxqhHi3EXM5SH+w@mail.gmail.com> <5637feb5.611a450a.bf33d.4307@mx.google.com> <CAAP42hBdMmtjReqwj=KDQ0XuTssqA1wiHgxgjD+0FHL+_mv_CA@mail.gmail.com> <563A2BCC.6030801@gmail.com>
To: Sergey Beryozkin <sberyozkin@gmail.com>
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/JUMbUPUzb3q8W85jf75p2uvEDqQ>
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Sharing a client_id: is it good or bad ?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 04 Nov 2015 22:20:48 -0000

For a native app you can have one clientID and no secret (same as having one secret for all of them) or you can use dynamic client registration to give each one a separate client_id and secret.

The middle ground is to use PKCE and no client secret.  

The client generates a pkce challenge in the authorization request and then presents the verifier.  You can then use that verifier to place a identifier for that app instance in the refresh/access tokens.   That would allow the RS to differentiate between two clients with the same user on different devices.  
That gets you more or less equivalent security, but binds the client instance to a user/device as part of the authorization flow,  rather than by creating separate client_id for each instance and managing that.

It is up to more of a deployer preference on what way to go.  

I prefer the PKCE route personally,  that requires a real user to be involved in the flow before the AS needs to store state.   In open dynamic client registration you can face a denial of service attack by creating unlimited clients, that is harder to manage.  

One thing that will be coming up at the WG meeting today is the possibility of extending PKCE verification to refresh tokens as well as there current use with code.  That would move the PKCE and client registration security even closer together.

John B.

> On Nov 5, 2015, at 1:01 AM, Sergey Beryozkin <sberyozkin@gmail.com> wrote:
> 
> Hi All
> 
> I'm having a discussion with my colleagues on the pros and cons of sharing a client_id.
> 
> For example, say we have N number of public mobile applications (the same application package, an application instance on an individual phone), and one approach is for each of these applications to have the same client_id.
> 
> I've been trying to analyze why it can be bad and the only thing I can come up with is that there will be no (easy) way to track which application instance actually accessed a given RS.
> 
> Can someone please explain what the pros and cons are of having the same client_id shared between public client applications.
> 
> And what about multiple confidential clients being set up with the same id/secret. I suspect it is a bad idea but what is main line why it is a bad idea, lets say it is all done in the protected network, no chance of the bad clients interfering...
> 
> 
> 
> Thanks, Sergey
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth