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

[Torsten Lodderstedt <[e-mail]>]

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



Forest <[e-mail]> schrieb:

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
<[e-mail]> 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.
>
>
>
>
> 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
>