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

Justin Richer <jricher@mit.edu> Tue, 26 January 2016 23:03 UTC

Return-Path: <jricher@mit.edu>
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 3FB581B32C5 for <oauth@ietfa.amsl.com>; Tue, 26 Jan 2016 15:03:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 nDI5LLUuNTtH for <oauth@ietfa.amsl.com>; Tue, 26 Jan 2016 15:03:17 -0800 (PST)
Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB061B32C1 for <oauth@ietf.org>; Tue, 26 Jan 2016 15:03:17 -0800 (PST)
X-AuditID: 12074422-f79c46d000006aa7-56-56a7fb34c241
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id B1.15.27303.43BF7A65; Tue, 26 Jan 2016 18:03:16 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id u0QN3Fmd030088; Tue, 26 Jan 2016 18:03:15 -0500
Received: from [192.168.128.48] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u0QN3Dtj014934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 26 Jan 2016 18:03:14 -0500
Content-Type: multipart/alternative; boundary="Apple-Mail=_B5AE43CA-7CAC-4D8E-8847-C74576C802AA"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Justin Richer <jricher@mit.edu>
In-Reply-To: <CAEayHEMrTjDQbdoX3C-2-oGUVVQTzCzDqbWU-hFeAtbSp-tCcg@mail.gmail.com>
Date: Tue, 26 Jan 2016 18:03:12 -0500
Message-Id: <7E08DFCA-ADBC-481A-896A-2725E1F79EFA@mit.edu>
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>
To: Thomas Broyer <t.broyer@gmail.com>
X-Mailer: Apple Mail (2.2104)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrEKsWRmVeSWpSXmKPExsUixG6nomvye3mYwc2JAhYn375is/i31N7i +L+LzBab5jSzO7B47Jx1l91jwaZSjyVLfjIFMEdx2aSk5mSWpRbp2yVwZZw62sVWcGkRY0XH qYVMDYxX2xi7GDk5JARMJKZPesUOYYtJXLi3nq2LkYtDSGAxk8Tsw7dZIZyNjBKTO66wQDi3 mST+777NBtLCLJAgcf/neTCbV0BP4tWty6wgtrCAr8SFj3fAxrIJqEpMX9PCBGJzCgRKXP41 F6yeBSi+7fovRpChzAKdjBJXz51lhhhkJdH1+yAzxLalTBKHdz4AmyoioCZx891GqMNlJXb/ fsQ0gVFgFpJDZiE5BCKuLbFs4WtmCFtTYn/3chZMcQ2Jzm8TWRcwsq1ilE3JrdLNTczMKU5N 1i1OTszLSy3SNdXLzSzRS00p3cQIjgoXpR2MPw8qHWIU4GBU4uE1OLQ8TIg1say4MvcQoyQH k5Iob+YLoBBfUn5KZUZicUZ8UWlOavEhRgkOZiUR3u+fgHK8KYmVValF+TApaQ4WJXHeXR1z w4QE0hNLUrNTUwtSi2CyMhwcShK88r+AGgWLUtNTK9Iyc0oQ0kwcnCDDeYCG84LU8BYXJOYW Z6ZD5E8xKkqJ8174CZQQAElklObB9YKSVsLbw6avGMWBXhHmFQdp5wEmPLjuV0CDmYAGH5QH G1ySiJCSamDMrbURlGja/lyUW0wnZsLN+G1uM+N2X/vw69DTdo2Xy37s1v07cfES7nd6G6al mSjzOi847LO+6JhI3O3dW3qP7P72onlb6syDp67obI3MZHfYeWH7dq9tIVNOL52/tvh5Ad8a a/PGZQJVsT9TFU5mZeSf0Jz0c+GH34/ljV/3ZHMtaBGV7HD+qcRSnJFoqMVcVJwIANKwMDU1 AwAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/WOjr1ac7c1TQJL0o_IHGOcY1e5Y>
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 23:03:21 -0000

In MITREid Connect we track grants per client_id per user, and we have a separate database object for storing them. I wouldn’t recommend simply updating an access token that’s already in the wild with more power — that just sounds wrong.

 — Justin

> On Jan 26, 2016, at 1:57 PM, Thomas Broyer <t.broyer@gmail.com>; wrote:
> 
> Fwiw, at Ozwillo, we track grants per user per client_id (we don't support native apps; only web flows for now), and we don't do "incremental grants" like Google: if you request scope B and the user had only granted scope A, you'll get a token for scope B only. This is partly because our tokens are not for our own APIs only, contrary to Google, so we want to allow clients to get tokens with narrow scopes so they could have one token per third-party API and prevent rogue resources from trying to use received tokens at other APIs.
> 
> UI-wise, we tell the user what he already granted to the client, and even let him grant scopes that the client has pre-registered as "possibly needed at some time" (through a custom provisioning protocol), but the issued token is always for the exact scopes that the client requested in this specific request.
> And if all requested scopes have already been granted, then we do a transparent redirect without showing anything to the user (which is what most other implementations do too)
> 
> Le mar. 26 janv. 2016 19:04, Sergey Beryozkin <sberyozkin@gmail.com <mailto:sberyozkin@gmail.com>> a écrit :
> 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>
> >> <mailto: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>
> >>         <mailto: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> <mailto: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> <mailto:OAuth@ietf.org <mailto:OAuth@ietf.org>>
> >>         https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> >>
> >>
> >>     _______________________________________________
> >>     OAuth mailing list
> >>     OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org <mailto:OAuth@ietf.org>>
> >>     https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> >>
> >>
> >
> >
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth