Re: [OAUTH-WG] Client credentials for native applications: seeking clarification

[Torsten Lodderstedt <[e-mail]>]

Hi,

there is no contradiction. The subtle difference lays in the word "instance". Using secrets for a software package (and all of its installations) is useless and therefore not allowed. If you are able to issue a distinct id/secret pair to every installation of your app, this is fine. 

For a the complete rationale pls. take a look into http://tools.ietf.org/html/draft-lodderstedt-oauth-security/.

The question is whether you really want to authenticate the client or the user. For users, resource owner password is an option. I agree with you that the user experience is bad. You may consider to use another device (pc, smartphone) to perform the authorization flow. You may take a look onto the device flow proposal. Alternatively, you could utilize the code flow on the secondary device and ask the user to enter the code on the TV Set.

regards,
Torsten.




Forest <[e-mail]> schrieb:

Hi there.

I've been considering OAuth 2 and its "client credentials" grant type
for use with applications that run on televisions and other consumer
devices. It is appealing mainly because it requires no built-in web
browser and no cumbersome data entry for the user. (Similar to the
Netflix device registration procedure.) However, I think I've run
into a snag.

Section 4.4 of draft-ietf-oauth-v2-22 says:
"The client credentials grant type MUST only be used by confidential clients."

Since Section 2.1 defines confidential clients as distinct from
"clients executing on the resource owner's device", I have the
impression that this forbids pretty much any device in the user's
possession from using client credentials. (Except perhaps the rare
gadget that embeds encrypted storage and physical safeguards against
key discovery.) I suppose this would mean OAuth 2 is unsuitable for
the task at hand.

However, Section 10.1 says:
"The authorization server MAY issue a client password or other
credentials for a specific installation of a native application client
on a specific device."

This seems to contradict Section 4.4, although if I understand it
correctly, it would allow me to use client credentials as I had hoped
without violating the spec. That's encouraging. Maybe I can use
OAuth 2 after all, so long as each installed instance of my
application gets its own credentials.

So, I could use some clarification on a few points:

1. Is that quote in Section 10.1 meant to be an exception to the one
in Section 4.4? If so, I would suggest rephrasing 4.4 to allow for
the exception and to make it easier for OAuth 2 implementors to
discover.

2. If it is not intended as an exception, meaning that apps running on
consumer devices are not to be issued client credentials, what is the
recommended alternative? Section 1.3.3 suggests resource owner
password credentials when "other authorization grant types are not
available", and using a "long-lived access token or refresh token". I
suppose this approach would enable OAuth on devices that have no web
browser, though it would create a usability problem by requiring users
to enter their credentials using awkward, frustrating input devices
(like 5-button remote controls). Perhaps more importantly, it begs
the question of how storing a long-lived token is any more secure than
storing client credentials. After all, both could grant access, both
could be revoked, and both could be exposed just as easily. Which
brings me to my third question:

3. From whom is a "confidential" client expected to keep its
credentials secret? From the resource owner? (I suppose this would
make sense for a server-side application trusted by many users, but it
makes little sense for a consumer device, since a user is unlikely to
give out his own device's credentials and could more easily give out
his own password.) From other applications running on the same
device? (This makes sense, but devices with sandboxed per-application
storage would seem to warrant an exception from the "clients executing
on the resource owner's device" generalization in Section 2.1.) From
the world at large? (If this is the only level of confidentiality
then I would think "clients executing on the resource owner's device"
would easily qualify as confidential.)

Thanks, all. I look forward to a better understanding of what is intended here.
_____________________________________________

OAuth mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/oauth