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

Sergey Beryozkin <sberyozkin@gmail.com> Thu, 05 November 2015 11:09 UTC

Return-Path: <sberyozkin@gmail.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 6DBB81ACDFB for <oauth@ietfa.amsl.com>; Thu, 5 Nov 2015 03:09:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 frAJK4z7qJKT for <oauth@ietfa.amsl.com>; Thu, 5 Nov 2015 03:09:35 -0800 (PST)
Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 4DC1F1A8AB8 for <oauth@ietf.org>; Thu, 5 Nov 2015 03:09:35 -0800 (PST)
Received: by wmww144 with SMTP id w144so4388415wmw.1 for <oauth@ietf.org>; Thu, 05 Nov 2015 03:09:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=tKbDWO2USM9XlyTBf0EguNOrbnYbAQi0vKRgvk7s68I=; b=wp/JOP4ru2Fb8nMXu2yIXiS/Q8cEdRgeX28z0e4OfKIcdC6GPoT8e54CWfE4OAp4um 6aA2AekOjc7tQN2hPx/f9BxJOZ/ZVjQmkVPniJx/Wi2DhTTKWayaGPS5EPNj+7J2gwNB mi7zCwxlc4BmTKmHoJp1t+XXmAhAUicslcxc5WPIWVPILBtrcHQeggyUXQAuiserWfMI QYCFhOjA6uIUPBvwJthxMZBYOe56APBuIrIg30vmh3NRzuFXOXQBWJYzRvRf+91PsfQj lNNLd21InKmhW7iXc4fa+q3tIg0/QnmaAL48wGeQLnCEVuQEP5wPRFU3G+lsLpwYrkYr UKNQ==
X-Received: by 10.28.174.144 with SMTP id x138mr2959282wme.28.1446721773802; Thu, 05 Nov 2015 03:09:33 -0800 (PST)
Received: from [10.36.226.98] ([80.169.137.63]) by smtp.googlemail.com with ESMTPSA id e63sm33544293wma.7.2015.11.05.03.09.32 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Nov 2015 03:09:32 -0800 (PST)
To: John Bradley <ve7jtb@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> <77B2A3DD-3C0F-49EB-AD7F-9C4DAA6542AE@ve7jtb.com>
From: Sergey Beryozkin <sberyozkin@gmail.com>
Message-ID: <563B38EC.6000401@gmail.com>
Date: Thu, 05 Nov 2015 11:09:32 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <77B2A3DD-3C0F-49EB-AD7F-9C4DAA6542AE@ve7jtb.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/6BFdsw6l3CUZ6ZnerRah3yxnYVk>
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: Thu, 05 Nov 2015 11:09:37 -0000

Hi John, and Jim

Thanks for the feedback
On 04/11/15 22:20, John Bradley wrote:
> 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.
>
We have a code dealing with the PKCE approach available on the server 
side, but I've had a little clue so far :-) about how practical it can 
be, thanks for the explanation, I'll have a deeper look, might ask a 
couple of questions later on...
> 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.
>
Thanks, Sergey

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