Re: [OAUTH-WG] Flowchart for legs of OAuth

Anthony Nadalin <tonynad@microsoft.com> Mon, 04 April 2011 19:11 UTC

Return-Path: <tonynad@microsoft.com>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F7A73A6452 for <oauth@core3.amsl.com>; Mon, 4 Apr 2011 12:11:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.409
X-Spam-Level:
X-Spam-Status: No, score=-7.409 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xy6MSv0zu0Ms for <oauth@core3.amsl.com>; Mon, 4 Apr 2011 12:11:50 -0700 (PDT)
Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 1E52F3A6407 for <oauth@ietf.org>; Mon, 4 Apr 2011 12:11:50 -0700 (PDT)
Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 4 Apr 2011 12:13:32 -0700
Received: from VA3EHSOBE005.bigfish.com (157.54.51.81) by mail.microsoft.com (157.54.79.178) with Microsoft SMTP Server (TLS) id 14.1.270.2; Mon, 4 Apr 2011 12:13:32 -0700
Received: from mail22-va3-R.bigfish.com (10.7.14.237) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.8; Mon, 4 Apr 2011 19:13:09 +0000
Received: from mail22-va3 (localhost.localdomain [127.0.0.1]) by mail22-va3-R.bigfish.com (Postfix) with ESMTP id 6CDDE9380D7 for <oauth@ietf.org.FOPE.CONNECTOR.OVERRIDE>; Mon, 4 Apr 2011 19:13:09 +0000 (UTC)
X-SpamScore: -53
X-BigFish: PS-53(zz1503M936eK9371P542N1432N98dKzzdafM1202h1082kzz1033IL8275dhz31h2a8h668h839h61h)
X-Spam-TCS-SCL: 0:0
X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPV:SKI; H:SN1PRD0302HT002.namprd03.prod.outlook.com; R:internal; EFV:INT
Received: from mail22-va3 (localhost.localdomain [127.0.0.1]) by mail22-va3 (MessageSwitch) id 1301944388921518_15567; Mon, 4 Apr 2011 19:13:08 +0000 (UTC)
Received: from VA3EHSMHS036.bigfish.com (unknown [10.7.14.251]) by mail22-va3.bigfish.com (Postfix) with ESMTP id DAC641410051; Mon, 4 Apr 2011 19:13:08 +0000 (UTC)
Received: from SN1PRD0302HT002.namprd03.prod.outlook.com (65.55.94.9) by VA3EHSMHS036.bigfish.com (10.7.99.46) with Microsoft SMTP Server (TLS) id 14.1.225.8; Mon, 4 Apr 2011 19:13:00 +0000
Received: from SN1PRD0302MB100.namprd03.prod.outlook.com ([169.254.10.226]) by SN1PRD0302HT002.namprd03.prod.outlook.com ([10.14.149.46]) with mapi id 14.01.0225.027; Mon, 4 Apr 2011 19:12:59 +0000
From: Anthony Nadalin <tonynad@microsoft.com>
To: Kris Selden <kris.selden@gmail.com>, Skylar Woodward <skylar@kiva.org>
Thread-Topic: [OAUTH-WG] Flowchart for legs of OAuth
Thread-Index: AQHL0ipTtjZaSpjXs0eFEWU3KTMxjpQz2uqAgAAT4ICAAAPGgIABMnkAgAZCNgCAAB0bAIAM0bmAgAAELICAABHMgIAF0E4AgAAEPQCAAAVGAIAADY8AgAAAyvA=
Date: Mon, 04 Apr 2011 19:12:58 +0000
Message-ID: <B26C1EF377CB694EAB6BDDC8E624B6E7114F1640@SN1PRD0302MB100.namprd03.prod.outlook.com>
References: <22FB565B-A701-4502-818F-15164D9E201A@oracle.com> <AANLkTimGjiCGk5dpA=YVzq5vDkLR2+caSz=pZ5WiZO9H@mail.gmail.com> <3C84AD7A-F00F-43EC-AAD3-AD2DCFB46B0E@oracle.com> <90C41DD21FB7C64BB94121FBBC2E7234464F432BB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D84F7E2.6090305@redhat.com> <16B9A882-6204-4CBD-B7E3-1D806AF5056C@oracle.com> <4D8A5054.4050006@lodderstedt.net> <BANLkTiniuuRXtkzLubgOjVursVtOGjFe6A@mail.gmail.com> <7616C235-2913-4EE0-A710-F47A4CC9E424@oracle.com> <BANLkTi=XyF25vB6qKX2q8iOpEaZ1yQx9Jw@mail.gmail.com> <65E3F250-5111-4692-BFA7-F5B838E9B41D@gmail.com> <9E68D140-ED3D-4C62-A6A1-5CE1CDB5C5D9@oracle.com> <2597C1CF-1067-404A-BFE3-DE8F55A77EA6@kiva.org> <66F1ABA3-4A1E-4B18-94D4-A431FA9DE126@gmail.com>
In-Reply-To: <66F1ABA3-4A1E-4B18-94D4-A431FA9DE126@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [131.107.0.107]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OrganizationHeadersPreserved: SN1PRD0302HT002.namprd03.prod.outlook.com
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%GMAIL.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%KIVA.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-OriginatorOrg: microsoft.com
X-CrossPremisesHeadersPromoted: TK5EX14MLTC101.redmond.corp.microsoft.com
X-CrossPremisesHeadersFiltered: TK5EX14MLTC101.redmond.corp.microsoft.com
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Mon, 04 Apr 2011 19:11:51 -0000

> I completely agree with you regarding not being able to authenticate a native client.

I suggest you read the security considerations draft to make sure this is correct and points out the issues

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Kris Selden
Sent: Monday, April 04, 2011 12:10 PM
To: Skylar Woodward
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth

I completely agree with you regarding not being able to authenticate a native client.

The problem with web flow is the user experience is bad for a native app.  Why does this matter?  Because of competition - if competitors use a user friendly but less secure method and the end user does not know it is bad for them, then because of market forces you have to do the same.

As a startup developer, I cannot tell the business side that our UI has to be worse than their Facebook app, Twitter client or Instagram on their phone because that isn't secure.  They're going to look at me like I'm crazy.

If the end user is ignorant, educating them comes at too high of a price for a startup.  The end user cares about their safety but assumes that big companies are the bar for security.


On Apr 4, 2011, at 11:21 AM, Skylar Woodward wrote:

> Having worked many years with native Internet consumer software applications, and having worked in those teams in attempt to secure client secrets (be they keys or obfuscated dynamic algorithms), I can say with reasonable confidence that it is impossible to secure client credentials for publicly available applications (where the same credential is shared against all instances of the application).  Both iPhone and PlayStation represent some of the most formidable efforts to secure secrets or data in publicly distributed consumer products.  Systems on these have been successfully broken and this will continue to be the case.  Even if someone has a new technology to propose that they think can prove this wrong, there is no reliable record of success for hiding secrets in the field. We should assume any system distributed for public review can be reverse engineered, and secrets obtained.
> 
> I propose that for the sake of this discussion, we continue with the assumption that no native apps with public distribution are able to have client secrets.
> 
> 
> (Btw, Kris seemed to be suggesting that users could be prompted to enter a (unique?) app ID and client secret, but this would complicate usability, working against the goals of OAuth in the first place. I'd agree - if native app users had to enter a custom client secret, they might as well obtain their own private access token and enter it instead, by passing OAuth completely).
> 
> On Apr 4, 2011, at 2:02 PM, Phil Hunt wrote:
> 
>> On 2011-04-04, at 10:47 AM, Kris Selden wrote:
>> 
>>> A typical iPhone app cannot be shipped with a client secret and rightly or wrongly users expect to only have to enter their credentials once.
>> 
>> My understanding (and I'm not an iOS expert) is that each iOS application has a secure keystore where the client credential could be stored. I am told this is fairly straight forward. The client app would issue a call out to the external safari browser for the authorization with a redirect back to the app registered (local redirect) such as myapp://authorization_code
> 

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth