[OAUTH-WG] Client credentials for native applications: seeking clarification
Forest <tadaforest@gmail.com> Fri, 21 October 2011 01:06 UTC
Return-Path: <tadaforest@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F7D611E8099 for <oauth@ietfa.amsl.com>; Thu, 20 Oct 2011 18:06:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gnn8BELyrnt for <oauth@ietfa.amsl.com>; Thu, 20 Oct 2011 18:06:03 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF6F11E8091 for <oauth@ietf.org>; Thu, 20 Oct 2011 18:06:03 -0700 (PDT)
Received: by bkas6 with SMTP id s6so4789636bka.31 for <oauth@ietf.org>; Thu, 20 Oct 2011 18:06:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=PIOCFzaA4xNb6Ovd1WFWfE7J2qvZYLbLwbdrwnFo7ts=; b=obuwZfY/SlkNQQWMvuaqVqY8lzhaSgjNWsB+q3tUZOEHpYs0o7vSpDIXzJ4200qHoH Nd4BYq7Paj5onGpriNHXlsMOR1bIMFfizrks+xg5/OPfoK/MS5+HVH9Wq9mY9ou6Ojor LviCCmZWo6W9zoaKx9KaoDLFfRXnPJLAsT6ug=
MIME-Version: 1.0
Received: by 10.204.148.68 with SMTP id o4mr9489889bkv.21.1319159161948; Thu, 20 Oct 2011 18:06:01 -0700 (PDT)
Received: by 10.204.49.21 with HTTP; Thu, 20 Oct 2011 18:06:01 -0700 (PDT)
Date: Thu, 20 Oct 2011 18:06:01 -0700
Message-ID: <CAFRu7dkSjEbMdb1Je5fnMiULZSP03frW5D8xh2zhS38=1O0s1g@mail.gmail.com>
From: Forest <tadaforest@gmail.com>
To: oauth@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Subject: [OAUTH-WG] Client credentials for native applications: seeking clarification
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Oct 2011 01:10:21 -0000
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-WG] Client credentials for native applicat… Forest
- Re: [OAUTH-WG] Client credentials for native appl… Torsten Lodderstedt
- Re: [OAUTH-WG] Client credentials for native appl… Forest
- Re: [OAUTH-WG] Client credentials for native appl… Torsten Lodderstedt