Re: [OAUTH-WG] OAuth Device Flow

Aaron Parecki <> Fri, 13 November 2015 20:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4D5E11B3108 for <>; Fri, 13 Nov 2015 12:46:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bxyHciRYF2O3 for <>; Fri, 13 Nov 2015 12:46:50 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6163D1B3107 for <>; Fri, 13 Nov 2015 12:46:50 -0800 (PST)
Received: by ioc74 with SMTP id 74so109326609ioc.2 for <>; Fri, 13 Nov 2015 12:46:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=hmqS7TksJ62OpKK37dZLdyxwWmGmLy84spx1QB2wCy4=; b=0D3IyE6hyLJKBvGYGjns7wSMvTL/hyPzwQuRH68h4tMpGH90pVR9rWN7Ge9bIUvFGO M94ngNKt0v3ITh9asr62Ko3bLMuXmn/AolQvfnTg2fswm5mxhSXNOlSom7uVSCzuRKJK jtiJLVWo6FY8iLFm02uTvK7KxvTCT/1JSno2xelA4d5ixYfLFpb7KAmtlhFhYdMNPGd0 liJKLQbcYKK4fXYKWqkivMTtbjGMB4k/5o+D+mtN4LO+YkM7Oe08CxiIZiqEmBIyKi2T nfW8639t2VxPaU+CTzEHqSTZnxULfXcRfjVYJyD+PCHOnCXOhY1H9TcXiSdItgaq7gVo GFkw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=hmqS7TksJ62OpKK37dZLdyxwWmGmLy84spx1QB2wCy4=; b=Cx6cY6LpCVYOEgYDQID5CaT0DLp/V0qkpMi1C19yObhprm0TpWy5rrVYmvqFzDLpyz zHVF6UrdBImjpZt+po8jztW3nR55uCvo8mZDsoHPt7XNEDj34xddue4SKD6xZiXANSWD u80tIZTmD3Tdvtgcd1GKqWFSJKDSIJhkwtzqgiqq4m1qA1TKU8rSGjIxKR+WVzMjSfda C4hbACVf58C+505+BCI7JYfFFS2OEkfCF7acJapBn9jKA6KQRFwqY1woZfyosZLYFJNh J+We5LKFtIcxI7ve6ww2ycsjSsC9mZ5PVTGtbmJYTGCxQpcKfuc+tRHhbgywkgHawAHt AOFw==
X-Gm-Message-State: ALoCoQnZwX/ZlCbWKn4SHBF/sX456Ya+piZph7kw8yjjEP2iyGkxXpvnNn4xRPC0rSfmW6lwdVXM
X-Received: by with SMTP id w8mr11176192iod.3.1447447609686; Fri, 13 Nov 2015 12:46:49 -0800 (PST)
Received: from ( []) by with ESMTPSA id n9sm1942998ige.16.2015. for <> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Nov 2015 12:46:48 -0800 (PST)
Received: by igbxm8 with SMTP id xm8so22064528igb.1 for <>; Fri, 13 Nov 2015 12:46:48 -0800 (PST)
MIME-Version: 1.0
X-Received: by with SMTP id t8mr5314265igr.16.1447447608559; Fri, 13 Nov 2015 12:46:48 -0800 (PST)
Received: by with HTTP; Fri, 13 Nov 2015 12:46:48 -0800 (PST)
In-Reply-To: <>
References: <>
Date: Fri, 13 Nov 2015 12:46:48 -0800
X-Gmail-Original-Message-ID: <>
Message-ID: <>
From: Aaron Parecki <>
To: "" <>, Hannes Tschofenig <>
Content-Type: multipart/alternative; boundary="047d7bdc05e88a1c5605247228aa"
Archived-At: <>
Subject: Re: [OAUTH-WG] OAuth Device Flow
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 13 Nov 2015 20:46:52 -0000

In reading this over, I noticed a subtle difference from the Facebook and
Google implementations, and I'm wondering if this was intentional or not.

Section 3.1 says "The authorization server prompts the end-user to
authorize the client's request by entering the end-user code provided by
the client." The introduction has even more explicitly different wording:
"(D) ... If the end-user agrees to the client's access request, the
end-user enters the end-user code provided by the client."

However this is different from Facebook and Google's implementations, which
work as follows:

   - Device shows the verification URI and code to the user
   - The user visits the URL and is prompted to sign in to the service
   (Google has the extra step of then choosing which Youtube account to use)
   - The user is then prompted to enter the device code
   - After entering the device code, the authorization prompt is displayed

In reading this draft, the implication is that the act of entering the code
also is the authorization. The problem is that the server won't know things
like the scope or application name until after the code is entered, so it
can't properly show an authorization prompt.

I think this needs to be reworded to separate entering the code from
showing the authorization prompt. I believe it is only a wording change.
Maybe something more like:

3.1 "The authorization server prompts the end-user to enter the end-user
code provided by the client, after which it prompts the end-user to
authorize the client's request."

and in the introduction:

1. (D) "The authorization server authenticates the end-user (via the
user-agent) and prompts the end-user to enter the end-user code provided by
the client. The authorization server validates the end-user code and
prompts the end-user to grant the client's access request."

Aaron Parecki
@aaronpk <>

On Wed, Nov 4, 2015 at 4:44 PM, Hannes Tschofenig <
> wrote:

> FYI: A couple of us got together and re-published an old, expired draft
> about the OAuth Device Flow.
> Here is the document:
> For the -00 version we tired to keep it inline with what has been
> available with draft-recordon-oauth-v2-device-00. In upcoming versions
> of this document we would like to capture existing deployment.
> Here are two deployment examples that are reasonably well described:
> - Google
> - Facebook
> Ciao
> Hannes
> _______________________________________________
> OAuth mailing list