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

From: Forest <[email-masked]>
Date: Thu, 20 Oct 2011 18:06:01 -0700

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.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 21 Oct 2011 10:38:40 +0200

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 <[email-masked]> schrieb:

Hi there.

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

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

---

From: Forest <[email-masked]>
Date: Fri, 21 Oct 2011 13:14:50 -0700

Thanks for the clarification.  The subtle difference makes sense to
me, and indeed was what prompted me to address this list in the first
place.

It *is* subtle, though, and the oauth-v2-22 draft doesn't even hint at
it until six sections after a very clear "MUST" statement apparently
forbidding this use of client credentials.  I nearly walked away from
OAuth 2 as soon as I read that bit in Section 4.4, and I suspect
others would do exactly that.  I only discovered the distinction
because I happened to read an additional twelve discouraging pages
past the apparent roadblock. So, for the sake of clarity in the
working draft and in the hope of widespread adoption, I suggest that
this subtle difference be stated alongside aforementioned MUST
statement.

I'll read the oauth-security rationale.  Thanks for the link.

I'm having trouble finding the current device flow proposal.  The last
mention of it I remember was an earlier oauth-v2 draft.  Can you send
me a current link?

Cheers,

Forest

On Fri, Oct 21, 2011 at 01:38, Torsten Lodderstedt
<[email-masked]> wrote:
> 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.
>
>
>
>
>> key
>> discovery.)  I suppose this would mean OAuth 2 is unsuitable for
>> the task at hand.
>>
>> ________________________________
>> OAuth mailing list
>> [email-masked]

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 22 Oct 2011 10:19:04 +0200

http://tools.ietf.org/html/draft-recordon-oauth-v2-device-00

Cheers,

Forest