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

[Paul Madsen <[e-mail]>]

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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>