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.bro...@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 <sberyoz...@gmail.com > <mailto:sberyoz...@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 <sberyoz...@gmail.com > >> <mailto:sberyoz...@gmail.com> > >> <mailto: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> > >> <mailto: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> <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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
