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

John Bradley <ve7jtb@ve7jtb.com> Tue, 26 January 2016 18:33 UTC

Return-Path: <ve7jtb@ve7jtb.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 6313D1B2B4E for <oauth@ietfa.amsl.com>; Tue, 26 Jan 2016 10:33:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham
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 mMwXwH6KX_Ws for <oauth@ietfa.amsl.com>; Tue, 26 Jan 2016 10:33:13 -0800 (PST)
Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (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 E248E1B2B48 for <oauth@ietf.org>; Tue, 26 Jan 2016 10:33:12 -0800 (PST)
Received: by mail-qg0-x230.google.com with SMTP id o11so146016392qge.2 for <oauth@ietf.org>; Tue, 26 Jan 2016 10:33:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=2XoQuxz1NBoDaXKbm1HLiVAEtbsofx6ModwPd13mbd4=; b=ngIczr0f+eXikaXDBF1qyR9dmdHv/AkzUxOXo7+F5tfvnojjpapgWLahn9pYx6xc6y FBkcrGJCJHtFrYFu+jjH+xhP5Ka0osPjbOW9znBD+XqMJw+Uc78BV/eY/9+wfC4cQWR8 X+iHZ9xQVrxNJ7ykbe/k3Tob9gi3C/TcgbCkD5BkonGNO4tnB2hklGGg7gnAuor7cFiq q0F+76zBj6Z3pvtZovQDMw2XrF2hBa3wWHCAa3/Nr5LBWUuFQc88lu8Rkh3A1IT7HeBT /hfWwYCp6M/Sw0mUtWiMLoMunuPgQ7CYrrbjBFuPxtxJjHijKWjHzJ7vXJGITu1IrseE pGjA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=2XoQuxz1NBoDaXKbm1HLiVAEtbsofx6ModwPd13mbd4=; b=gn3zRBhu7ovHwKnxCS/047GrVihrW6TFSXZSAUZd1s3XOeasEjcHNeNjIF7CCcD1MV a11PSCrEy84HKBJu0mvFBoN/bW8JhcIBWNEcP3FEWnjk9zGy+3VrwVpNgRWXkNy0iF1m XDoDiomqGtIkMgUgNkh/Lg9gR9TV993Ms5S+MZxXOY+LpzZQjuosDD8yRED+abxmGHBH p3rEKGrCJGXYZqEqP+llEx8t+ceWs4BC6be9z+QcbaP6QaR3RNyVmTNn7W78WVYzBLcf HGg8XV5aadFmatpCZYX6FtULwQu+O366rkU0X9JijeYntbQ3UaQ5uFF3Wado7dqC4Uy0 GhWw==
X-Gm-Message-State: AG10YOTZyJ0kkzod+Cki+7nxjBAkzHQOaDiIw6EtabApEnWwa1eUB50xuzGdY/Jlue34uw==
X-Received: by 10.140.91.73 with SMTP id y67mr29802904qgd.42.1453833192004; Tue, 26 Jan 2016 10:33:12 -0800 (PST)
Received: from [192.168.8.100] ([181.202.129.132]) by smtp.gmail.com with ESMTPSA id l107sm1002847qge.22.2016.01.26.10.33.09 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 26 Jan 2016 10:33:10 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_1934DC06-00C7-4E98-9A9F-93DECBBA0CF1"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <56A7B52C.2040302@gmail.com>
Date: Tue, 26 Jan 2016 15:33:08 -0300
Message-Id: <2DB022F1-390B-41B1-9416-97D9F10DA129@ve7jtb.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>
To: Sergey Beryozkin <sberyozkin@gmail.com>
X-Mailer: Apple Mail (2.3112)
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/cUdNt-rP1BrxP6E-AT6QW7vrV24>
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: Tue, 26 Jan 2016 18:33:15 -0000

The grants should be tied to the refresh token, or a grant record tied to the confidential client.  

For native iOS I have seen  people bind it to the client_id if the client is not confidential.  That way if the user installs the same app on another device it gets the same grants.
I am however not a big fan of that and prefer to keep the grants segmented per device.   

John B.



> On Jan 26, 2016, at 3:04 PM, Sergey Beryozkin <sberyozkin@gmail.com>; wrote:
> 
> Hi
> 
> I'm not sure if the next question is off topic or too low level, hopefully not,
> 
> When the repeated authorization is skipped or only new scopes are requested to be authorized as per the incremented auth approach, is it reasonable to assume that the record that is used to track it all is actually the existing access token or is totally OIDC implementation specific ?
> I think using the existing token as a record is reasonable because it is time scoped and if we do not use the access token for keeping the track of the multiple approvals, etc, then one need to introduce one more record mirroring to some extent the access token...
> 
> For example, the user session may have expired but the access token that was issued to a client web app on behalf of this user is still active, so when the user returns and signs in again, and for example, approves few more scopes, then the existing access token (the record) gets updated, instead of a new token being created.
> 
> If it is reasonable then does it mean the sticky or incremental authorization works as long as the access token is available (refreshable) ?
> 
> Sergey
> 
> 
> 
> 
> On 19/01/16 09:59, Sergey Beryozkin wrote:
>> Hi William
>> 
>> Thanks for the advice. FYI we are also on the way to supporting the
>> incremental authorization of scopes - thanks for highlighting the
>> importance of this process on this list...
>> 
>> Cheers, Sergey
>> On 19/01/16 03:10, William Denniss wrote:
>>> Agree with Justin, this is pretty common. We support it for re-auth as
>>> well as incremental auth (where the user has already approved scope "a"
>>> and is presented with a request for scopes "a b", they will only need to
>>> approve scope "b").  In fact if you don't do this, then incremental auth
>>> isn't really viable.
>>> 
>>> Regarding security: don't do this for non-confidential clients where you
>>> can't verify the identity of the app by the redirect (e.g. a localhost
>>> redirect to an installed app).
>>> 
>>> On Mon, Jan 18, 2016 at 4:44 AM, Sergey Beryozkin <sberyozkin@gmail.com
>>> <mailto:sberyozkin@gmail.com>> wrote:
>>> 
>>>    Hi Justin, thanks for the advice,
>>> 
>>>    Cheers, Sergey
>>> 
>>>    On 18/01/16 11:47, Justin Richer wrote:
>>> 
>>>        Yes, this is common practice. Give the user the option to
>>>        remember the
>>>        decision. This is known as "trust on first use", or tofu. Our
>>>        server,
>>>        MITREid Connect, implements this as do many others.
>>> 
>>> 
>>> 
>>>        -- Justin
>>> 
>>>        / Sent from my phone /
>>> 
>>> 
>>>        -------- Original message --------
>>>        From: Sergey Beryozkin <sberyozkin@gmail.com
>>>        <mailto:sberyozkin@gmail.com>>
>>>        Date: 1/18/2016 5:59 AM (GMT-05:00)
>>>        To: oauth@ietf.org <mailto:oauth@ietf.org>
>>>        Subject: [OAUTH-WG] Can the repeated authorization of scopes be
>>>        avoided ?
>>> 
>>>        Hi All
>>> 
>>>        The question relates to the process of showing the authorization
>>>        code/implicit flow consent screen to a user.
>>> 
>>> 
>>>        I'm discussing with my colleagues the possibility of avoiding
>>>        asking the
>>>        same user whose session has expired and who is re-authenticating
>>>        with AS
>>>        which scopes should be approved.
>>> 
>>>        For example, suppose the OAuth2 client redirects a user with the
>>>        requested scope 'a'. The user signs in to AS and is shown a
>>> consent
>>>        screen asking to approve the 'a' scope. The user approves 'a'
>>>        and the
>>>        flow continues.
>>> 
>>>        Some time later, when the user's session has expired, the user is
>>>        redirected to AS with the same 'a' scope.
>>> 
>>>        Would it be a good idea, at this point, not to show the user the
>>>        consent
>>>        screen asking to approve the 'a' scope again ? For example, AS
>>> can
>>>        persist the fact that a given user has already approved 'a' for
>>>        a given
>>>        client earlier, so when the user re-authenticates, AS will use
>>>        this info
>>>        and will avoid showing the consent screen.
>>> 
>>>        That seems to make sense, but I'm wondering, can there be some
>>>        security
>>>        implications associated with it, any recommendations/advices
>>>        will be welcome
>>> 
>>>        Sergey
>>> 
>>>        _______________________________________________
>>>        OAuth mailing list
>>>        OAuth@ietf.org <mailto:OAuth@ietf.org>
>>>        https://www.ietf.org/mailman/listinfo/oauth
>>> 
>>> 
>>>    _______________________________________________
>>>    OAuth mailing list
>>>    OAuth@ietf.org <mailto:OAuth@ietf.org>
>>>    https://www.ietf.org/mailman/listinfo/oauth
>>> 
>>> 
>> 
>> 
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth