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

George Fletcher <> Mon, 19 December 2011 19:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1EE1911E8098 for <>; Mon, 19 Dec 2011 11:11:03 -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 TM1F949E7ftA for <>; Mon, 19 Dec 2011 11:11:02 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B6DA111E8097 for <>; Mon, 19 Dec 2011 11:11:01 -0800 (PST)
Received: from ( []) by (8.14.1/8.14.1) with ESMTP id pBJJAZxg023524; Mon, 19 Dec 2011 14:10:35 -0500
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (MUA/Third Party Client Interface) with ESMTPSA id 1A00EE0000BC; Mon, 19 Dec 2011 14:10:35 -0500 (EST)
Message-ID: <>
Date: Mon, 19 Dec 2011 14:10:34 -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="------------050103020805040908030501"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20110426; t=1324321835; bh=at68fPV0jSEZoHqvJBG9PjJOsRLTO+5Xkk1KQ6YPciU=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=fVMOcS37Spo67amDU/RsDp6urdNlheeMSBIbbUzftiEom/U7ZsqPL9KTLFn9t97PG N1rJLnjsJGfMRQfKdzEs65p3T5Futx94sgJzZ/kZxC0QDv5Ko5etKZFJN6dSWINkxa DQwl7/5ljDzb/J2tpHgEkLFq5rOrb0T4eALDeWU0=
X-AOL-SCOLL-SCORE: 0:2:458373632:93952408
x-aol-sid: 3039ac1d29044eef8c2b2ecc
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 19:11:03 -0000

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?

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.

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.

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:)


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