Re: [OAUTH-WG] Native clients & 'confidentiality'
zhang.ruishan@zte.com.cn Thu, 22 December 2011 02:58 UTC
Return-Path: <zhang.ruishan@zte.com.cn>
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 734F011E809C; Wed, 21 Dec 2011 18:58:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.085
X-Spam-Level:
X-Spam-Status: No, score=-100.085 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100]
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 jUNHxspdr4eL; Wed, 21 Dec 2011 18:58:23 -0800 (PST)
Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 86FE511E8097; Wed, 21 Dec 2011 18:58:22 -0800 (PST)
Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 59528609479330; Thu, 22 Dec 2011 10:56:41 +0800 (CST)
Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 95341.2621071999; Thu, 22 Dec 2011 10:58:13 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id pBM2w8rm056802; Thu, 22 Dec 2011 10:58:08 +0800 (GMT-8) (envelope-from zhang.ruishan@zte.com.cn)
In-Reply-To: <B26C1EF377CB694EAB6BDDC8E624B6E73BFD93AE@BL2PRD0310MB362.namprd03.prod.outlook.com>
To: Anthony Nadalin <tonynad@microsoft.com>
MIME-Version: 1.0
X-KeepSent: FBB7FCC2:A3164010-4825796E:000A5AC6; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: <OFFBB7FCC2.A3164010-ON4825796E.000A5AC6-4825796E.00104FD1@zte.com.cn>
From: zhang.ruishan@zte.com.cn
Date: Thu, 22 Dec 2011 10:58:04 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-12-22 10:58:09, Serialize complete at 2011-12-22 10:58:09
Content-Type: multipart/alternative; boundary="=_alternative 00104FCE4825796E_="
X-MAIL: mse01.zte.com.cn pBM2w8rm056802
Cc: oauth-bounces@ietf.org, "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Native clients & 'confidentiality'
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: Thu, 22 Dec 2011 02:58:24 -0000
In theory, if only native clients could keep deployment-time secret undisclosed, then we can say they are confidential clients. Actually, if native client applications are difficult to be reverse-enginnered, e.g., Skype, it's possible to gain the above goal. However, in most existing mobile apps, I guess reverse engieering should be quite easy. In this case, there is almost no way for these apps to hide anything. Best wishes, Ruishan deployment-time secrets Not really sure how you came to the conclusion that native mobile clients can’t be confidential? As pointed out in section 3.7 of the http://www.ietf.org/id/draft-ietf-oauth-v2-threatmodel-01.txt there are guidelines that confidential clients should follow, but does not distinguish between native clients or native mobile clients. From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer Sent: Monday, December 19, 2011 9:44 AM To: Paul Madsen Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Native clients & 'confidentiality' Native mobile clients can't really be confidential clients. The distinction between "public" and "confidential" clients is whether or not they can keep deployment-time secrets; which is to say, a client_secret. This is not to say that they can't keep *any* secrets. In particular those generated at runtime, like an access token or refresh token, could be held perfectly safe. But at the time the app is deployed to its running environment, you have to ask "who has access to its code and configuration?" Think of it this way. In the standard world, a native app gets copied to every device with the client_id and client_secret baked in. This makes the client_secret not very secret, and not at all unique. Anybody with access to the binary -- which is to say, every user -- could decompile the client_secret out of it and bake it into their *own* client, pretending to be your app and causing all kinds of havoc. This is a very different problem from somebody breaking into the token store and stealing an access token, which lets them only get to their own account. Compare this to a server-based app where the only ones with access to the binary and configuration are the administrators of the server, not the end users. It's a much more limited list of folks that can potentially see it, and therefore the client_secret can actually mean something and add a small extra layer of security. There are a few ways to mitigate this difference for public clients, such as using some kind of dynamic registration for all clients (which doesn't buy you much in terms of overall security) or putting up scary messages about native clients to try and educate your users. You can also use a trusted callback URL for your app on a hosted website that works in conjunction with your native app. This is actually the suggested use for the Implicit Flow, which was made for public clients in the browser. Native apps also have the concern of embedded browsers vs. external native browsers, and what trust the user puts into them. For all OAuth flows, you have to trust the browser provider on the platform of choice, since the user's going to be logging in directly through that browser. It's very much outside the scope of OAuth to make that world any better though, and there have been long and detailed discussions on this list about that very topic, leading to some concrete recommendations in the draft as it stands today. To answer your original query: I don't think that mandating one kind of client vs. the other will really help. OAuth 1.0 only had "confidential" clients, and that led to inane workarounds like Google's "anonymous/anonymous" client id/secret. Hope this helps. -- Justin On 12/19/2011 07:19 AM, Paul Madsen wrote: Hi, the Online Media Authorization Protocol (OMAP) is a (as yet unreleased) profile of OAuth 2.0 for online delivery of video content based on a user's subscriptions (the TV Everywhere use case) We want to support both server & native mobile clients. It is for the second class of clients that I'd appreciate some clarification of 'confidentiality' as defined in OAuth 2. OAuth 2 distinguishes confidential & public clients based on their ability to secure the credentials they'd use to authenticate to an AS - confidential clients can protect those credentials, public clients can't. Notwithstanding the above definition, the spec gives a degree of discretion to the AS The client type designation is based on the authorization server's definition of secure authentication and its acceptable exposure levels of client credentials. Give this discretion, is it practical for the OMAP spec to stipulate that 'All Clients (both server & native mobile), MUST be confidential', ie let each individual OMAP AS specify its own requirements of clients and their ability to securely authenticate? Is this consistent with the OAuth definition of confidentiality? Thanks Paul _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
- Re: [OAUTH-WG] Native clients & 'confidentiality' Michael Thomas
- Re: [OAUTH-WG] Native clients & 'confidentiality' Justin Richer
- Re: [OAUTH-WG] Native clients & 'confidentiality' Paul Madsen
- Re: [OAUTH-WG] Native clients & 'confidentiality' Michael Thomas
- Re: [OAUTH-WG] Native clients & 'confidentiality' Michael Thomas
- Re: [OAUTH-WG] Native clients & 'confidentiality' Michael Thomas
- Re: [OAUTH-WG] Native clients & 'confidentiality' Paul Madsen
- Re: [OAUTH-WG] Native clients & 'confidentiality' Paul Madsen
- [OAUTH-WG] Native clients & 'confidentiality' Paul Madsen
- Re: [OAUTH-WG] Native clients & 'confidentiality' Anthony Nadalin
- Re: [OAUTH-WG] Native clients & 'confidentiality' George Fletcher
- Re: [OAUTH-WG] Native clients & 'confidentiality' Justin Richer
- Re: [OAUTH-WG] Native clients & 'confidentiality' John Kemp
- Re: [OAUTH-WG] Native clients & 'confidentiality' John Kemp
- Re: [OAUTH-WG] Native clients & 'confidentiality' Paul Madsen
- Re: [OAUTH-WG] Native clients & 'confidentiality' Paul Madsen
- Re: [OAUTH-WG] Native clients & 'confidentiality' John Kemp
- Re: [OAUTH-WG] Native clients & 'confidentiality' Paul Madsen
- Re: [OAUTH-WG] Native clients & 'confidentiality' George Fletcher
- Re: [OAUTH-WG] Native clients & 'confidentiality' zhang.ruishan
- Re: [OAUTH-WG] Native clients & 'confidentiality' Eran Hammer
- Re: [OAUTH-WG] Native clients & 'confidentiality' Paul Madsen