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

[George Fletcher <[e-mail]>]

The difference might be whether you want to store the scope consent by 
client "instance" vs client_id application "class". Assuming that the 
client is not using dynamic client registration, then storing scope 
consent by client_id applies to all instances of that client. In most 
cases this is sufficient. However, if you want to store scope consent on 
a client instance basis and are not using dynamic client registration, 
then you would need to introduce something that can be used to represent 
the client instance. The access token could be such a mechanism.

Thanks,
George

On 1/27/16 7:17 AM, Sergey Beryozkin wrote:
> 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/
>>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth