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@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
