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

Sergey Beryozkin <sberyozkin@gmail.com> Wed, 27 January 2016 12:17 UTC

Return-Path: <sberyozkin@gmail.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 908BA1A87EA for <oauth@ietfa.amsl.com>; Wed, 27 Jan 2016 04:17:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 reZOzlL2b6cN for <oauth@ietfa.amsl.com>; Wed, 27 Jan 2016 04:17:09 -0800 (PST)
Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 39E421A87DB for <oauth@ietf.org>; Wed, 27 Jan 2016 04:17:09 -0800 (PST)
Received: by mail-wm0-x22c.google.com with SMTP id n5so23499810wmn.0 for <oauth@ietf.org>; Wed, 27 Jan 2016 04:17:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=3CNoYF+Sio8U7hSTWJAHQHbERvW47E3J28I5BB2FwJU=; b=ldjipiMtp2kaxAT4UY9VR1koSwW7WDn+SNjeo/AAFFe7t1dmB0Pwiw28dIWf6PgovJ /PLVkUw5Zl4pCAH2OOeKGi899X/Z+GhTTaEO6HBel+uF21EZGbz1Mh9vn3M/C83ZjSF+ ogDXVFid+6p1oHcc0YX7VDaYtis+5JKiMDx+3zBiVkWvbILyFBae36z9f1AMaub1wWxc nh5yV6sh82wAJTEqB2eSh5vw4CYU0pkV7AJL+1VAW316++TSjFM85TN+CCM9sS0pwPkX sS0kKSIARIaj+crLe+r8lwwHXBPxCpXI6BG1YtZnq1iUBO/dUyjqv3v1vqIY0p8QX4UQ 3EYA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=3CNoYF+Sio8U7hSTWJAHQHbERvW47E3J28I5BB2FwJU=; b=VMMJBbrg3sUczNEwq+UTw1nhTT1hNl3CWcaNmVrLRy3PD+CpW2PlpKYgPRlf66F48v vVGlAl6ecaQGDsbgpOESDnAwui3k74zKti2Xdgtcu+IVf9n/JenR4pjk0TrVb9wbODpc EdZPxPOkcsnS8aXm4t95TGNwSc4t0qSgps3xs9j3jImT6rDghzpVWii1Jm9gYdHwyHty fyn96/aZxJXi/zgMQUmvROe6796JBUkQJCW6klhDTAeQkuuvxyzDIiwQHmW4dxdWIljj MSplG4KEUtB48WAZQSKiTWwhOgv4uW6JfbS7ljLoPeFCmjIVec/4oFTf/6T9EFnYj6I3 ZybQ==
X-Gm-Message-State: AG10YORctoECHg97/2Rch++gIqbF9YdVpDpwG8VxfFBjuW6hi/uSshzWWlrUYkUBAUU7PA==
X-Received: by 10.28.225.132 with SMTP id y126mr30600288wmg.98.1453897027866; Wed, 27 Jan 2016 04:17:07 -0800 (PST)
Received: from [10.36.226.98] ([80.169.137.63]) by smtp.googlemail.com with ESMTPSA id kw1sm5984216wjb.12.2016.01.27.04.17.06 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Jan 2016 04:17:06 -0800 (PST)
To: Thomas Broyer <t.broyer@gmail.com>, Justin Richer <jricher@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> <7E08DFCA-ADBC-481A-896A-2725E1F79EFA@mit.edu> <56A8A762.9080004@gmail.com> <CAEayHEPi7hsu=zkr_qxadp02D9zzLGVDU-AGVZXzm25vE2bJFw@mail.gmail.com>
From: Sergey Beryozkin <sberyozkin@gmail.com>
Message-ID: <56A8B542.5060208@gmail.com>
Date: Wed, 27 Jan 2016 12:17:06 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <CAEayHEPi7hsu=zkr_qxadp02D9zzLGVDU-AGVZXzm25vE2bJFw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/0rEfeLYXbu0Ec1IlkwwWJJEvNGw>
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 12:17:12 -0000

Your English is better than mine :-), thanks for the feedback.

Well, I guess it can become quite implementation specific. We keep the 
the list of authorized scopes in the access token record, and if this 
access token can also be refreshed then I guess it can be a long term 
record (as far as preserving the history of the scopes previously 
authorized by a given a user for a given client)...Perhaps this is not 
ideal and may need to be reviewed....

Sergey

On 27/01/16 12:02, Thomas Broyer wrote:
> As fat as I'm concerned, grant==authorisation (English is not my native
> language so forgive me if I'm misusing some words).
> When the user clicks the authorize button on the consent screen, we save
> the scopes in the database. Tokens are independent from that (except for
> the business rules that we don't issue a token for a scope that hasn't
> been authorized and will revoke tokens for scopes that the user later
> "unauthorizes"), each token has its list of scopes maintained
> independently from the list of authorized scopes.
>
>
> Le mer. 27 janv. 2016 12:17, Sergey Beryozkin <sberyozkin@gmail.com
> <mailto:sberyozkin@gmail.com>> a écrit :
>
>     Hi,
>
>     Many thanks to all who provided the feedback.
>
>     As far as the existing token update is concerned I was thinking about it
>     in the context of the incremental authorization which we haven't
>     implemented yet so we'll need to review how to handle it later on.
>
>     Right now we are only prototyping the code for not challenging the user
>     with a consent screen if the requested scopes have already been approved
>     (per a given user + client id combination, and which is a base for
>     supporting the incremental auth at a next step).
>
>     I'm a bit confused about the use of a 'grant' term in your replies.
>
>     So consider a confidential client redirecting the user and requesting
>     some scope, as part of the authorization code flow. The user authorizes
>     the client and the client gets a code *grant* which is according to the
>     spec can live for up to *10 min*. The client exchanges this grant for a
>     token with the token preserving the fact the user has authorized a given
>     scope for this client. I guess this is all quite common.
>
>     Note the code 'grant' has already gone by now, because it was already
>     used once, withing a 10 mins period, which is another spec requirement.
>
>     That is why I'm referring to the existing access token record which can
>     be used for keeping the track of the scopes approved by a given user for
>     a given client. This token can be refreshed if needed.
>
>     When the user's session with a confidential client's web app has
>     expired, the user is redirected to authenticate, with some scopes
>     requested. At this point the record which keeps the approved scopes for
>     a given user/client is an existing access/refresh token.
>
>     This is why I'm confused about the use of the 'grant' term in your
>     replies. I guess this can be a 'grant' record for keeping the list of
>     the approved scopes/etc not related to a record representing a transient
>     authorization code record. But as I said, using the live access/refresh
>     token info seems reasonable, sorry, may be it is becoming too
>     implementation specific...
>
>     Cheers, Sergey
>
>
>
>
>
>     On 26/01/16 23:03, Justin Richer wrote:
>      > 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
>     <mailto:t.broyer@gmail.com>
>      >> <mailto:t.broyer@gmail.com <mailto: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>
>      >> <mailto: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>>
>      >>     >> <mailto: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>>
>      >>     >>         <mailto: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>>
>      >>     <mailto: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>>
>     <mailto:OAuth@ietf.org <mailto:OAuth@ietf.org>
>      >>     <mailto:OAuth@ietf.org <mailto:OAuth@ietf.org>>>
>      >>     >> 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>>
>     <mailto:OAuth@ietf.org <mailto:OAuth@ietf.org>
>      >>     <mailto:OAuth@ietf.org <mailto:OAuth@ietf.org>>>
>      >>     >> 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
>      >>
>      >> _______________________________________________
>      >> 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
>      >
>
>
>     --
>     Sergey Beryozkin
>
>     Talend Community Coders
>     http://coders.talend.com/
>