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

George Fletcher <> Wed, 21 December 2011 13:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 20CB121F8A70 for <>; Wed, 21 Dec 2011 05:56:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oty61kODlvSq for <>; Wed, 21 Dec 2011 05:56:19 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 716C221F8A64 for <>; Wed, 21 Dec 2011 05:56:19 -0800 (PST)
Received: from ( []) by (8.14.1/8.14.1) with ESMTP id pBLDttTp011230; Wed, 21 Dec 2011 08:55:55 -0500
Received: from palantir.local (unknown []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (MUA/Third Party Client Interface) with ESMTPSA id D5910E000081; Wed, 21 Dec 2011 08:55:54 -0500 (EST)
Message-ID: <>
Date: Wed, 21 Dec 2011 08:55:53 -0500
From: George Fletcher <>
Organization: AOL LLC
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Paul Madsen <>
References: <> <> <> <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------010803070705040202000104"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20110426; t=1324475755; bh=mt8btd8w01NlpjKhli34CeZeT0TOyfOjvLbRcSLQscE=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=LKGBa1z66ltcqZBg2xtn6hcUdA2Kz7D5Axn2tYhKKoLrXXXW4qT09ayYchssNz84N /JwrpJlNm9uc18+KKNbAhg0akR5Rtq4Dd8nQB1fIUFSlcK8TZQOxCsOoJPt6/vXKBj lXb3OJjqyO1E2blI3zLMuxNW9UTdXx/fb1mr+4xQ=
X-AOL-SCOLL-SCORE: 0:2:460849248:93952408
x-aol-sid: 3039ac1d29064ef1e56a7698
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: Wed, 21 Dec 2011 13:56:21 -0000

More inline:)

On 12/19/11 3:11 PM, Paul Madsen wrote:
> Hi George, inline
> thanks
> paul
> On 12/19/11 2:10 PM, George Fletcher wrote:
>> Hi Paul,
>> Is the need to authenticate the client a need to ensure that the 
>> content is only displayed on certain devices/clients? Or prevent 
>> phishing/stealing of authz bearer tokens?
> I'm not best qualified to answer but I believe it's the latter, ie not 
> DRM motivated
>> As you point out, it's possible to protect the bearer tokens and 
>> associated refresh tokens "via other mitigating mechanisms". I'm not 
>> sure it's possible to authenticate the device/client with out the 
>> device/client having some special "hardware" that can be leveraged in 
>> the authentication step.
> are you referring to a 'bootstrap' problem?
Well... more thinking about whether the set of devices/clients allowed 
to go through the "dynamic registration" process is "restricted" in some 
way (e.g. a certain manufacturer, or application running on a device). 
Given that the dynamic registration steps can be discovered, it become 
difficult to restrict what devices/clients can go through the dynamic 
registration steps.

>> Even dynamic registration doesn't solve the security issues (the 
>> device/client can still be disassembled and associated values 
>> discovered) of the device/client, just mitigates the exposure risk. 
>> However, this does cause increased work for the AS as it will now be 
>> tracking each and every device as a unique client. It's also likely 
>> for the device registration steps to be discovered, in which case 
>> restricting to a particular device again fails.
> yes, but as you imply an attacker will only access those credentials 
> specific to that particular copy of the native client. Hopefully too 
> much work to be able to see Glee Season 2.
> Can you clarify what you mean about the device registration steps 
> being 'discovered'?
(see above). Basically, the question becomes... is any device/client ok 
to be used as long as it goes through the dynamic registration process 
and is "authorized" by the AS? If the answer is yes, then I think 
dynamic registration is a great solution.  Given all transactions are 
over SSL, getting any of client credentials, refresh_token or 
access_token is going to be difficult without access to the device/client.

There is the issue of the client sending the token to a rogue protected 
resource. Though that is pretty unlikely based on a native 
device/client. It would require a both a rogue client and a rogue 
protected resource. If this is a concern, then you are sort of back into 
the problem of needing to be able to at least identify the device/client.

Seems like a unique set of client credentials for every instance of the 
device/client plus short-lived access_tokens should be good enough for 
this use case. The associated refresh_token can always be revoked as 
well. All this doesn't obviate the need for "risk based authN/authZ" at 
the AS.
>> It seems like trying to bind the bearer token to a device/client 
>> instance might be a better approach. That way you know that the 
>> customer correctly authorized that device/client instance and it is 
>> "allowed" to present the bearer token. Of course enforcing/proving 
>> the "allowed" part sort of breaks the "bearer" part:)
> yeah, how do we bind a bearer token to anything? :-) Doesnt that by 
> definition take us towards MAC?
I know, I'm stating the obvious... but thankfully it sounds like you 
don't need that level of security:)
>> Thanks,
>> George
>> On 12/19/11 1:09 PM, Paul Madsen wrote:
>>> 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
>>> paul
>>> 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
>>> _______________________________________________
>>> OAuth mailing list