On 12/19/2011 09:44 AM, 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?"
Ah, thank you. The draft could be a *lot* more explicit about that in its
definitions. After reading it several times, I couldn't figure out who
"public"
was to whom.
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.
As far as I can tell, the recommendations don't work.
Mike
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
