IETF Logo Mail Archive

Re: [OAUTH-WG] Device Flow: Alternative to Polling

Aaron Parecki <aaron@parecki.com> Fri, 21 October 2016 22:35 UTC

Return-Path: <aaron@parecki.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 2DEE0129691 for <oauth@ietfa.amsl.com>; Fri, 21 Oct 2016 15:35:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DaLTjJzyx8m8 for <oauth@ietfa.amsl.com>; Fri, 21 Oct 2016 15:35:53 -0700 (PDT)
Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD4B91295A3 for <oauth@ietf.org>; Fri, 21 Oct 2016 15:35:52 -0700 (PDT)
Received: by mail-ua0-x229.google.com with SMTP id m11so8674857uab.3 for <oauth@ietf.org>; Fri, 21 Oct 2016 15:35:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=TcJoAo6TEzU6Pj30nXjRv9upTSFFI6Af+UjX7oAH6Jo=; b=bpNrZ/sB3ey4yn48y8Z9eOL/RePxs4ckJdeBXpxOD0Qw+YjLnE2LKWwlXCFvrhbb+F Hu1jiP7oDvUegp6yg1kvklCCjMXW+jq1GKf1MXt8BYfi3jaFCnSRCHBAVjBq24a1+ZSV d3q6vBResJDS6sfnZe9ngLCxc0ANHujXUs1vCtXukaVmH9BYN7axr29djVnr7Z51+EgY YFbS0N59d6reguGZNXh3xh5ditJsMrbQSg9TdV+4Ma+MX50zO0ZUQGRDs8NAOOCmhjQM pWa3nzsuMqto7/crGm42WmzC4HJdFoDPaFp0cJEM2Fmh7XDImERwzF9XQFoigtoVzueV bVLw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=TcJoAo6TEzU6Pj30nXjRv9upTSFFI6Af+UjX7oAH6Jo=; b=DLkhUUR29c6KOuUfDhu5V4sh2HvTMBfnmfHsem0YcsSFJXA5pDKNhimC6LRd0ZwyCV dxteegA4FkrbfGgqW/59GW351J3qmFdLRIVvxWF+mOn+rfh+LwR2dt6prrYDbzjI8vyi J2AhpDZrNxum2ApIjvUBdplOicF7ahMEfLOWyCk1xU4F4qHT7NuGfT8MrgtC9ZWshuOr 2wYQGL11EFC+94+vwzL63fl44gLmCpub9tzjK+Y0C2N5AwWy0+j/tpoFh45OR+DOrzoG feGA+Q9wzwpskhw9V1T1p6Ze178a3a6g0fYJ96MfZqe2qqdkoETuef821a08jp7IuoJ8 f9xQ==
X-Gm-Message-State: ABUngveKQvAK7TXf35a2d7xMeGBtyNSxJFUlZ8/JHqvIscGNWquRw+8IsHRKCXWf3drssw==
X-Received: by 10.159.33.246 with SMTP id 109mr1562033uac.33.1477089351732; Fri, 21 Oct 2016 15:35:51 -0700 (PDT)
Received: from mail-ua0-f180.google.com (mail-ua0-f180.google.com. [209.85.217.180]) by smtp.gmail.com with ESMTPSA id 37sm1075116uaj.7.2016.10.21.15.35.51 for <oauth@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Oct 2016 15:35:51 -0700 (PDT)
Received: by mail-ua0-f180.google.com with SMTP id r64so8656662uar.2 for <oauth@ietf.org>; Fri, 21 Oct 2016 15:35:51 -0700 (PDT)
X-Received: by 10.176.67.199 with SMTP id l65mr1537703ual.101.1477089351056; Fri, 21 Oct 2016 15:35:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.223.67 with HTTP; Fri, 21 Oct 2016 15:35:50 -0700 (PDT)
In-Reply-To: <8b540eff-2b1c-2d9f-6d40-2be327f91eb7@gmx.net>
References: <8b540eff-2b1c-2d9f-6d40-2be327f91eb7@gmx.net>
From: Aaron Parecki <aaron@parecki.com>
Date: Fri, 21 Oct 2016 15:35:50 -0700
X-Gmail-Original-Message-ID: <CAGBSGjoO3LiA4NZ9tKrK1KHzBY2MkbfG+XNu_1tnFAptjSnZzQ@mail.gmail.com>
Message-ID: <CAGBSGjoO3LiA4NZ9tKrK1KHzBY2MkbfG+XNu_1tnFAptjSnZzQ@mail.gmail.com>
To: "oauth@ietf.org" <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="001a114d826a124bac053f67aa60"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/r3XgdOdOtFuxaswBDDFOdZHFI4Y>
Subject: Re: [OAUTH-WG] Device Flow: Alternative to Polling
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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 2016 22:35:55 -0000

Part of the beauty of the current device flow spec is that it's so simple
to support. Keeping that simplicity is crucial especially for this, since
this flow is used by a variety of devices that often do not have higher
level stacks.

I would love to hear from someone who has experience with large-scale
deployments of this to know whether polling is even a problem in the first
place.

----
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>

----
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>


On Fri, Oct 21, 2016 at 3:23 PM, Hannes Tschofenig <
hannes.tschofenig@gmx.net> wrote:

> Hi all,
>
> the device flow document outlines the case when an OAuth interaction
> gets "outsourced" to a separate device in order to allow user
> authentication and collecting the consent.
>
> The exchange is described in Section 1 of
> https://tools.ietf.org/html/draft-ietf-oauth-device-flow-03.
>
> Here is the step that was raised during the discussions:
>
>       (E) While the end-user authorizes (or denies) the client's request
>       (D), the client repeatedly polls the authorization server to find
>       out if the end-user completed the end-user authorization step.
>       The client includes the verification code and its client
>       identifier.
>
> The question was whether we could come up with an alternative to polling
> since this step could potentially take some time. Hence, it would be
> better if the authorization server has a way to send a message to the
> client without polling. Of course, the polling frequency matters and how
> quickly one (e.g., user) wants to know about the successful authorization.
>
> So, the first question is whether polling is considered as a problem in
> the first place.
>
> If so, then the question is how this could be addressed and (from work
> in other areas) there are really only two approaches:
>
> 1) We make use of some protocol that keeps the connection open and allow
> asynchronous communication. HTTP/2 and Websockets come to mind.
>
> 2) The client can be addressed through some push notification mechanism,
> such as by running an HTTP server on the device that can then be used by
> the authorization server.
>
> Any views about this topic?
>
> Ciao
> Hannes
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

v2.23.0 | Report a Bug | By Email