Re: [OAUTH-WG] Can the repeated authorization of scopes be avoided ?

William Denniss <wdenniss@google.com> Wed, 27 January 2016 17:48 UTC

Return-Path: <wdenniss@google.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 931C51AD0C9 for <oauth@ietfa.amsl.com>; Wed, 27 Jan 2016 09:48:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level:
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
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 pJ1Fk0C3kgJM for <oauth@ietfa.amsl.com>; Wed, 27 Jan 2016 09:48:15 -0800 (PST)
Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (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 5EDAA1AD0BA for <oauth@ietf.org>; Wed, 27 Jan 2016 09:48:15 -0800 (PST)
Received: by mail-oi0-x232.google.com with SMTP id k206so10346405oia.1 for <oauth@ietf.org>; Wed, 27 Jan 2016 09:48:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=4kXFljx5LMJ9KdeA77zCzc+IvttuuC32kXRwEv1dVHg=; b=R1eQvSdCEQhm7+Fl9cZQYtTVYxyxJgMgiPfdlUT2T7bwiOsAovoRCBtLnJkiXRsSKD l/jS7ltr/aGBQST2FB1L54++BJDe9PRBuzVuxJB4YocIlN36zXC7WaOq7Z/k68PBWdW7 GuhJnNJVDAUKnSfiCHRfKsCztmLGhVbrsMHD94IfOUGyzBY+FAHCb/oiPnLvqCCR0Gfo MKeBC/06T2VcFSGPTRm1XccneISn9DGxu59g6iLWbH2H2IACPPI76zo9iYTN1aUdgEgv K3sJiUBkm3+tedG4TqzEHBGZ9uqo/lsJgIq32ABu3+xcOcqqcVFO3A9cyDZ8kfmSpfXE 9iYg==
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:cc:content-type; bh=4kXFljx5LMJ9KdeA77zCzc+IvttuuC32kXRwEv1dVHg=; b=ZkBkJ2akO0RDfYl70AYJKP66mIzxnjnq6y/y0CqPeJy5E2fVUb0dMyMrQHiTRUzLEQ bO1Ac3HpY/9csvMlrA7sXUkAwDzPPdUlFCCniWRIcHb7QexrXApUlEwY+zgJVJkgzYYF xQKGAT2hrRQMcNKKEP4+eJ97A8h2/Elpd3nkNlaF4AZSvyMofRAHzr/tN64/b5F5Lf+F C8NlMU2GFRVLoDTaVNldt9INBI4tMGdPDRLT9dVVDCO3lwynliXQs4ihAXqKXn0Gq7yl +gloz4naosdrTqOVcn1HkaWxgb2L0O7IA8Gd74p483yvwoewmP27fuzr/hTWRJOTRjPO Aw5Q==
X-Gm-Message-State: AG10YOQytci+mFyOVsD7e4vZ3T5FK7FAmruooJ7uDNKhtsMQWmXXVejBdrP0UMT0Acblz3TjZb9D8rWk9nt4A5sU
X-Received: by 10.202.179.70 with SMTP id c67mr20032143oif.12.1453916894418; Wed, 27 Jan 2016 09:48:14 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.227.39 with HTTP; Wed, 27 Jan 2016 09:47:54 -0800 (PST)
In-Reply-To: <56A8FA46.60807@gmail.com>
References: <78kleo9cmvytysxs1qv8kep0.1453117674832@email.android.com> <569CDE25.90908@gmail.com> <CAAP42hA_3EmJw7fAXSSfg=KynAMF26x6vgm1HyLX1RAS4OpKfQ@mail.gmail.com> <569E08F6.4040600@gmail.com> <56A7B52C.2040302@gmail.com> <CAEayHEMrTjDQbdoX3C-2-oGUVVQTzCzDqbWU-hFeAtbSp-tCcg@mail.gmail.com> <7E08DFCA-ADBC-481A-896A-2725E1F79EFA@mit.edu> <56A8A762.9080004@gmail.com> <CAEayHEPi7hsu=zkr_qxadp02D9zzLGVDU-AGVZXzm25vE2bJFw@mail.gmail.com> <56A8B542.5060208@gmail.com> <56A8BE1B.2080404@aol.com> <CAEayHEOtpUxMRKduitbe=D3UFHSazMmkf9UQoiPNjZFr0JATOA@mail.gmail.com> <56A8F3A5.8060002@aol.com> <56A8F612.7040208@aol.com> <56A8FA46.60807@gmail.com>
From: William Denniss <wdenniss@google.com>
Date: Wed, 27 Jan 2016 09:47:54 -0800
Message-ID: <CAAP42hBFaCFBJwekjDZ+EO-A_U9Vc9FasaUFnerEzS7n1KYKRQ@mail.gmail.com>
To: Sergey Beryozkin <sberyozkin@gmail.com>
Content-Type: multipart/alternative; boundary=001a113cdf3806a279052a5468ef
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/UPFRMasDhyExwJ2vxz8o5KThEi4>
Cc: "<oauth@ietf.org>" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Can the repeated authorization of scopes be avoided ?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 27 Jan 2016 17:48:17 -0000

In our implementation we mostly record grants as per-user, per-client_id.
However, we treat public clients whose identity we can't verify as
ineligible for incremental auth. The reason is if a client is
counterfeiting another client, we don't want to return previous
authorizations (the user should at least have to grant permissions in the
context of this other counterfeiting application).  For a public client
where the return path can be guaranteed by the OS (e.g. Universal Links on
iOS), this rule can be relaxed, so it's more about public clients whose
identity cannot be verified (e.g. custom URI scheme, or localhost redirect).

I have an idea for how to solve those unverifiable clients too, where the
client would prove its previous authorization grant by providing the
current access token on the new "incremental" authorization request.

For verifiable clients, we have an option to "snowball" tokens and include
previous grants (with the exception of some scopes that need per-device
approval), using the non-standard param include_granted_scopes
<https://developers.google.com/identity/protocols/OAuth2WebServer#incrementalAuth>;.
Such a request results in a new token being issued with potentially
increased scope, we don't automatically increase the scope of previously
issued tokens.

Perhaps this group could consider standardizing Incremental OAuth. There
are valuable lessons & techniques that several people here have learnt and
implemented over the years, as shown by this thread. I might be willing to
put together a draft.



On Wed, Jan 27, 2016 at 9:11 AM, Sergey Beryozkin <sberyozkin@gmail.com>;
wrote:

> Hi George
>
> Thanks. I think I'll need to spend more time on thinking about the way it
> has to be implemented, but I guess one thing I realize is that using only
> access tokens as records for this purpose is not ideal/generic.
>
> That said, it is not clear to me that a per-instance level consent makes
> sense only when the dynamic registration is used.
>
> Suppose we have a statically registered client, with the client id shared
> between 100 devices or even confidential clients. I'm actually not sure how
> realistic it is that the same user works with more than one device sharing
> the same id, but assuming it is possible sometimes, and further, with
> incremental authentication in place,
>
> we can have a situation where while working on device1 a user has approved
> 'a' while on device2 - scope "b", with both devices sharing the same client
> id.
>
> May be I'm making it too complex :-)
>
> Thanks, Sergey
>
> On 27/01/16 16:53, George Fletcher wrote:
>
>> My recommendation, like the others, is to store consent by
>> client_id:user and then try and leverage dynamic client registration if
>> instance level consent is needed.
>>
>> On 1/27/16 11:43 AM, George Fletcher wrote:
>>
>>> Yes, I was thinking mostly of "native apps"... though you bring up a
>>> good point. It would be great if "installable" web apps could do
>>> dynamic client registration:)  I suppose for a "public" client that is
>>> loaded onto a device, the "installation" process could obtain a new
>>> client_id for that instance. Cookies might work, or have the app
>>> generate a unique identifier and use that in conjunction with the
>>> client_id?
>>>
>>> Thanks,
>>> George
>>>
>>> On 1/27/16 11:07 AM, Thomas Broyer wrote:
>>>
>>>>
>>>>
>>>> On Wed, Jan 27, 2016 at 1:54 PM George Fletcher <gffletch@aol.com
>>>> <mailto:gffletch@aol.com>> wrote:
>>>>
>>>>     The difference might be whether you want to store the scope
>>>>     consent by client "instance" vs client_id application "class".
>>>>
>>>>
>>>> Correct me if I'm wrong but this only makes sense for "native apps",
>>>> not for web apps, right?
>>>> (of course, now with "installable web apps" –e.g. progressive web
>>>> apps–, lines get blurry; any suggestion how you'd do it then? cookies?)
>>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>>
>
> --
> Sergey Beryozkin
>
> Talend Community Coders
> http://coders.talend.com/
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>