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 <sberyoz...@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 <sberyoz...@gmail.com >>> <mailto:sberyoz...@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 <sberyoz...@gmail.com >>> <mailto:sberyoz...@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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
