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

[Sergey Beryozkin <[e-mail]>]

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 <[e-mail]
> <mailto:[e-mail]>> 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 <[e-mail]
>     <mailto:[e-mail]>
>      >> <mailto:[e-mail] <mailto:[e-mail]>>> 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
>     <[e-mail] <mailto:[e-mail]>
>      >> <mailto:[e-mail] <mailto:[e-mail]>>> 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
>      >>     <[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
>      >>     >> <mailto:[e-mail]
>     <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>>> 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 <[e-mail]
>     <mailto:[e-mail]>
>      >>     <mailto:[e-mail] <mailto:[e-mail]>>
>      >>     >>         <mailto:[e-mail]
>     <mailto:[e-mail]>
>      >>     <mailto:[e-mail] <mailto:[e-mail]>>>>
>      >>     >>         Date: 1/18/2016 5:59 AM (GMT-05:00)
>      >>     >>         To: [e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
>      >>     <mailto:[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>>
>      >>     >>         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
>      >>     >> [e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
>     <mailto:[e-mail] <mailto:[e-mail]>
>      >>     <mailto:[e-mail] <mailto:[e-mail]>>>
>      >>     >> https://www.ietf.org/mailman/listinfo/oauth
>      >>     >>
>      >>     >>
>      >>     >>     _______________________________________________
>      >>     >>     OAuth mailing list
>      >>     >> [e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
>     <mailto:[e-mail] <mailto:[e-mail]>
>      >>     <mailto:[e-mail] <mailto:[e-mail]>>>
>      >>     >> https://www.ietf.org/mailman/listinfo/oauth
>      >>     >>
>      >>     >>
>      >>     >
>      >>     >
>      >>
>      >>     _______________________________________________
>      >>     OAuth mailing list
>      >> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>
>      >> https://www.ietf.org/mailman/listinfo/oauth
>      >>
>      >> _______________________________________________
>      >> OAuth mailing list
>      >> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>
>      >> https://www.ietf.org/mailman/listinfo/oauth
>      >
>
>
>     --
>     Sergey Beryozkin
>
>     Talend Community Coders
>     http://coders.talend.com/
>