Re: [OAUTH-WG] Native clients & 'confidentiality'

Paul Madsen <> Mon, 19 December 2011 18:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E39C121F8B47 for <>; Mon, 19 Dec 2011 10:09:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.598
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 50i1qFAHQtH6 for <>; Mon, 19 Dec 2011 10:09:58 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 8076C21F8B38 for <>; Mon, 19 Dec 2011 10:09:57 -0800 (PST)
Received: by faas1 with SMTP id s1so3884924faa.31 for <>; Mon, 19 Dec 2011 10:09:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=o+skX1xydGT05xJ7D8Uk4eD8zQqfiw1Iqcl0BbcPhKU=; b=LS2EHMLbZYPgqgTwtXlGID6OYxlfcymtzOQpwRr8sa1VJsQEEyI91SF6pKCQIBXenj QNJdg2MId0Wijck1iOjOyta27TceNDMhLaQ/XF8PVKxanEu7jGnnBZ0ks3jgllG0Q+ti Mf6wFGzlI4G6wcjbHA/brW7BZXpY2QdY7LmoA=
Received: by with SMTP id o5mr1031381wiy.1.1324318194883; Mon, 19 Dec 2011 10:09:54 -0800 (PST)
Received: from pmadsen-mbp.local ( []) by with ESMTPS id ei9sm26854319wid.0.2011. (version=SSLv3 cipher=OTHER); Mon, 19 Dec 2011 10:09:53 -0800 (PST)
Message-ID: <>
Date: Mon, 19 Dec 2011 13:09:51 -0500
From: Paul Madsen <>
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: Justin Richer <>
References: <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------090506070806000007020306"
Subject: Re: [OAUTH-WG] Native clients & 'confidentiality'
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 19 Dec 2011 18:09:59 -0000

Thanks Justin, FWIW, I agree with your analysis

Seems to me we have the following breakdown of clients

- confidential server clients

- confidential native clients (somewhat theoretical at the moment, 
assumes either 1) a client registration mechanism to deliver credentials 
post installation, such as OpenID Connects Client Registration spec, or 
2) a distribution channel in which uniquely credentials can be packaged 
into the binary before delivery)

- public clients (no option of client authn, but still possible to have 
some protection against token leakage via other mitigating mechanisms)

thanks again


On 12/19/11 12:44 PM, Justin Richer wrote:
> 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 itpractical 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