IETF Logo Mail Archive

Re: [OAUTH-WG] OAuth2 security considerations for client_id

Paul Madsen <paul.madsen@gmail.com> Fri, 06 January 2012 17:48 UTC

Return-Path: <paul.madsen@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 72DE921F896B for <oauth@ietfa.amsl.com>; Fri, 6 Jan 2012 09:48:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 mZi18sbSFyrP for <oauth@ietfa.amsl.com>; Fri, 6 Jan 2012 09:48:25 -0800 (PST)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9AEFE21F8769 for <oauth@ietf.org>; Fri, 6 Jan 2012 09:48:25 -0800 (PST)
Received: by vcbfk13 with SMTP id fk13so1520160vcb.31 for <oauth@ietf.org>; Fri, 06 Jan 2012 09:48:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=zulfVYOUNOxhLPRW6MjJ3v6NjvAcX93RORJK0peEV4k=; b=wswliGpXhHf1dowZXxjthtsBI4jPNwUXmtjQrHtFyAWigHB5IxBzpZw0BZo9BY34cG J97G9I5n1mSQKFNrqCyQjzADOuVWMbul0SRrqFRgOV2yOFVTgoS4ttwCRePH8V2OP+xU y5ZMIdKdUu8K5ZQuU4hcouMLbmV76MdP7h+fg=
Received: by 10.220.149.135 with SMTP id t7mr4227712vcv.34.1325872105142; Fri, 06 Jan 2012 09:48:25 -0800 (PST)
Received: from pmadsen-mbp.local (CPE0022b0cb82b4-CM0012256eb4b4.cpe.net.cable.rogers.com. [72.136.168.159]) by mx.google.com with ESMTPS id bj19sm18197781vdc.16.2012.01.06.09.48.23 (version=SSLv3 cipher=OTHER); Fri, 06 Jan 2012 09:48:24 -0800 (PST)
Message-ID: <4F0733E6.2000308@gmail.com>
Date: Fri, 06 Jan 2012 12:48:22 -0500
From: Paul Madsen <paul.madsen@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: William Mills <wmills@yahoo-inc.com>
References: <CACHRFsBNqUgXPxgFth-zHL=tvkVHy=OCXK2tcQ6hC273eoJ9EQ@mail.gmail.com> <0f4aff4b-9fcc-4077-9fca-a068ebf97dd4@email.android.com> <1325871268.64118.YahooMailNeo@web31809.mail.mud.yahoo.com>
In-Reply-To: <1325871268.64118.YahooMailNeo@web31809.mail.mud.yahoo.com>
Content-Type: multipart/alternative; boundary="------------040205070105040705070908"
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth2 security considerations for client_id
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 Jan 2012 17:48:26 -0000

William, presumably you meant 'client_secret'?

And is it fair to say that this reflects the current reality (of app 
distribution channels & OS protections) more so than any inherent mobile 
client limitation?

paul

On 1/6/12 12:34 PM, William Mills wrote:
> Yeah, certainly for Mobile clients this is true.  There are classes of 
> clients (server to server implementations notably) where clientID can 
> be a proper secret and be usefule for client validation.
>
> ------------------------------------------------------------------------
> *From:* Torsten Lodderstedt <torsten@lodderstedt.net>
> *To:* Karim <medkarim.esskalli@gmail.com>; oauth@ietf.org
> *Sent:* Friday, January 6, 2012 5:21 AM
> *Subject:* Re: [OAUTH-WG] OAuth2 security considerations for client_id
>
> Hi,
>
> your observation is correct. OAuth security considerations recommend 
> not to rely on secrets for authenticating mobile apps (aka native 
> apps) but to manage them as so-called public clients. Please take a 
> look onto section 10 of the core spec for further details.
>
> regards,
> Torsten.
>
>
>
> Karim <medkarim.esskalli@gmail.com> schrieb:
>
>     Hello,
>
>     When using User-agent flow with OAuth2 for mobile platform, there
>     is no way for Authorization server to authenticate the client_id
>     of the application.
>
>     So, anyone can impersonate my app by copying the client_id (and so
>     get all access tokens on my behalf), and this is applicable to
>     Facebook, Foursquare,...
>
>     This is not managed by OAuth2 ? Or I missed something ?
>
>     For Web applications (Web server flow), access token is stored on
>     the server side, and the client is authenticated using secret key.
>
>     -- 
>     Karim
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

v2.23.0 | Report a Bug | By Email