Return-Path: 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 1109621F85BD for ; Fri, 6 Jan 2012 10:24:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.241 X-Spam-Level: X-Spam-Status: No, score=-17.241 tagged_above=-999 required=5 tests=[AWL=0.357, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 Nt56CsRtnnyb for ; Fri, 6 Jan 2012 10:24:28 -0800 (PST) Received: from nm15.bullet.mail.sp2.yahoo.com (nm15.bullet.mail.sp2.yahoo.com [98.139.91.85]) by ietfa.amsl.com (Postfix) with SMTP id CE99621F84EB for ; Fri, 6 Jan 2012 10:24:28 -0800 (PST) Received: from [98.139.91.69] by nm15.bullet.mail.sp2.yahoo.com with NNFMP; 06 Jan 2012 18:24:28 -0000 Received: from [98.139.91.42] by tm9.bullet.mail.sp2.yahoo.com with NNFMP; 06 Jan 2012 18:24:28 -0000 Received: from [127.0.0.1] by omp1042.mail.sp2.yahoo.com with NNFMP; 06 Jan 2012 18:24:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 745492.83603.bm@omp1042.mail.sp2.yahoo.com Received: (qmail 25561 invoked by uid 60001); 6 Jan 2012 18:24:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1325874268; bh=XCBK3h2GpU4ZQgkETPzvttYTIi2qYITcd1V+2Ptkgos=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=W74WlPG2fkOlC7FRu0KHX8ProRO6JMuLZdBxQOKHwC9ag1H4UQExVNxY73Ewv0pXEtaz0CyYl+2REpVmYsDoXvTKuYIwfYVdhgyYbtxG5LYRL6HUbwmSolo4YavmWJjlClTvZW+6GBDlv/6+x9bL5QjLlciWq5m/9YoGE0QASA8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ZsrBBxMGw/TKnwwOjMXPvu1X6QiwDRUbnz7SBeABMhqlIoelevVHgi2ptKM+e5cWZGIsGap1In7kPD+zgyi3zTCCf0UI5nrVF8v1JtRJuCMtMIDfKe4bnQ010zejGu0cVSDPHX2A1KcJkOOOdLdgpcbDddHc1EqhAkQD7AU9rYM=; X-YMail-OSG: lkrKetAVM1lOPHzCDY36NMRrFGivRFWfizIs30iZ_WkjFhp lRZQVmnLIDQED4BHT4Pu_YNKSr04A2pztU8xCEfesHUrE4QgF_JJDI0OY1fM c7JtOshlbt.8Ves2D5JDMTPef3Cb9xSZbkK6sJFC0xdQMrtycRSJe.h2MJeA 9JQhcEWnIo2oj4t0mCP8WNIBNy0jR6wQix.BqYGC0w_bLGK_720LPJL0jOqi Hso0Zqm7B_l.nKrBWXRv.rAKYS36Ps6XxHwcQIpHYnmFi6_hGkvrD73RODHG 4UGJzI21t1JOXLWFSbR5Zfsy5g.QF2.Y942xsDzVkpDmT3nCoorIKSmVrdrK GH22dV94h361oxesPpknBFMDKQ6kvJiHcw31T1uvZ7X5imWi8zNGaUTwoOSP JaIDja7gtpEdGXURngU6QN3vGKK2O2SMV8IsS2g-- Received: from [209.131.62.115] by web31807.mail.mud.yahoo.com via HTTP; Fri, 06 Jan 2012 10:24:28 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.116.331537 References: <0f4aff4b-9fcc-4077-9fca-a068ebf97dd4@email.android.com> <1325871268.64118.YahooMailNeo@web31809.mail.mud.yahoo.com> <4F0733E6.2000308@gmail.com> Message-ID: <1325874268.38071.YahooMailNeo@web31807.mail.mud.yahoo.com> Date: Fri, 6 Jan 2012 10:24:28 -0800 (PST) From: William Mills To: Paul Madsen In-Reply-To: <4F0733E6.2000308@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-125733401-1557728781-1325874268=:38071" Cc: "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 Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 18:24:30 -0000 ---125733401-1557728781-1325874268=:38071 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Yeah, I sure did.=A0 Client ID being the moral equivalent of user agent str= ing in a browser.=0A=0A=0A=0A________________________________=0A From: Paul= Madsen =0ATo: William Mills = =0ACc: Torsten Lodderstedt ; Karim ; "oauth@ietf.org" =0ASent: Friday, January = 6, 2012 9:48 AM=0ASubject: Re: [OAUTH-WG] OAuth2 security considerations fo= r client_id=0A =0A=0AWilliam, presumably you meant 'client_secret'?=0A=0AAn= d is it fair to say that this reflects the current reality (of app=0A di= stribution channels & OS protections) more so than any=0A inherent mobil= e client limitation?=0A=0Apaul=0A=0AOn 1/6/12 12:34 PM, William Mills wrote= : =0AYeah, certainly for Mobile clients this is true.=A0 There are classes = of clients (server to server implementations notably) where clientID can be= a proper secret and be usefule for client validation.=0A>=0A>=0A>=0A>=0A>_= _______________________________=0A> From: Torsten Lodderstedt =0A>To: Karim ; oauth@ietf.org =0A= >Sent: Friday, January 6, 2012 5:21 AM=0A>Subject: Re: [OAUTH-WG] OAuth2 se= curity considerations for client_id=0A> =0A>=0A>Hi,=0A>=0A>your observation= is correct. OAuth security considerations=0A recommend not to= rely on secrets for authenticating mobile=0A apps (aka native= apps) but to manage them as so-called=0A public clients. Plea= se take a look onto section 10 of the=0A core spec for further= details.=0A>=0A>regards,=0A>Torsten.=0A>=0A>=0A>=0A>=0A>Karim schrieb: =0A>Hello,=0A>>=0A>>=0A>>When using User-agent f= low with OAuth2 for mobile platform, there is no way for Authorization serv= er to authenticate the client_id of the application.=0A>>=0A>>=0A>>So, anyo= ne can impersonate my app by copying the client_id (and so get all access t= okens on my behalf), and this is applicable to Facebook, Foursquare,...=0A>= >=0A>>=0A>>This is not managed by OAuth2 ? Or I missed something ?=0A>>=0A>= >=0A>>For Web applications (Web server flow), access token is stored on the= server side, and the client is authenticated using secret key.=0A>>=0A>>= =0A-- =0A>>Karim=0A>>=0A>>=0A>_____________________________________________= __=0A>OAuth mailing list=0A>OAuth@ietf.org=0A>https://www.ietf.org/mailman/= listinfo/oauth=0A>=0A>=0A>=0A>=0A>=0A>_____________________________________= __________=0AOAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman= /listinfo/oauth ---125733401-1557728781-1325874268=:38071 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Yeah, I sure did.  Client ID being the moral equivalent of user agen= t string in a browser.

From: Paul Madsen <paul.madsen@g= mail.com>
To: Willi= am Mills <wmills@yahoo-inc.com>
Cc: Torsten Lodderstedt <torsten@lodderstedt.net>; Ka= rim <medkarim.esskalli@gmail.com>; "oauth@ietf.org" <oauth@ietf.or= g>
Sent: Friday, J= anuary 6, 2012 9:48 AM
Subject:= Re: [OAUTH-WG] OAuth2 security considerations for client_id
 =0A
=0A =0A=0A =0A =0A
=0A William, presumably you meant 'client_secret'?
=0A =
=0A And is it fair to say that this reflects the current reality (= of app=0A distribution channels & OS protections) more so than any= =0A inherent mobile client limitation?
=0A
=0A paul
=0A =
=0A On 1/6/12 12:34 PM, William Mills wrote:=0A
=0A
= =0A
Yeah, certainly for Mobile clients this is true. = ;=0A There are classes of clients (server to server=0A = implementations notably) where clientID can be a proper=0A sec= ret and be usefule for client validation.
=0A
=0A =

=0A
=0A
=0A =
=0A
= From:=0A Tors= ten Lodderstedt <torsten@lodderstedt.net>
=0A = To: Karim=0A = <medkarim.esskalli@gmail.com>; = oauth@ietf.org
=0A Sent:=0A Friday, January 6, 2012 5:21 AM
=0A = Subject:=0A = Re: [OAUTH-WG] OAuth2 security considerations for=0A = client_id
=0A
=0A
Hi,
=0A
=0A your observation is co= rrect. OAuth security considerations=0A recommend not to rely = on secrets for authenticating mobile=0A apps (aka native apps)= but to manage them as so-called=0A public clients. Please tak= e a look onto section 10 of the=0A core spec for further detai= ls.
=0A
=0A regards,
=0A T= orsten.
=0A
=0A

=0A
=0A Karim <medkarim.esskalli@gmail.com> schrieb:=0A =
=0A =
Hello,
=0A

=0A =
=0A
When using User-agent flow with OA= uth2 for mobile=0A platform, there is no way for Authori= zation server=0A to authenticate the client_id of the ap= plication.
=0A

=0A
= =0A
So, anyone can impersonate my app by copying the= =0A client_id (and so get all access tokens on my=0A = behalf), and this is applicable to Facebook,=0A = Foursquare,...
=0A

=0A =
=0A
This is not managed by OAuth2 ? Or I mi= ssed=0A something ?
=0A

= =0A
=0A
For Web applications (= Web server flow), access=0A token is stored on the serve= r side, and the client=0A is authenticated using secret = key.
=0A

=0A
=0A = --
=0A Karim
=0A
= =0A
=0A
=0A =0A
=0A ________________________________________= _______
=0A OAuth mailing list
=0A OAuth@ietf.org
=0A https:= //www.ietf.org/mailman/listinfo/oauth
=0A
=0A =
=0A
=0A
=0A
=0A
=0A=
=0A =
=0A 
_______________________________________________=0AOAu=
th mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth=0A<=
/pre>=0A
=0A
=0A=0A


---125733401-1557728781-1325874268=:38071--