If you are building your security based on a multi-factor model, it would seem that password events might actually be one of the lesser value triggers for changing or invalidating tokens.
Example: a hacker exploits password reset process to invalidate the legit person's access to an account, and by doing so they invalidate all existing access tokens successfully taking over ALL access to the account. It might be reasonable to have an existing authorized client be able to initiate special account recovery procedures as a backup assuming there is a higher value of trust in the client app. I think token invalidation should be based on other issues like suspicious client activity or client credential rotation, etc. Phil @independentid www.independentid.com [email protected] On 2013-08-07, at 5:24 PM, Bill Mills <[email protected]> wrote: > Yahoo generally, but not always (there are special cases), invalidates all > credentials on password change. This applies to refresh tokens, access > tokens, cookies, etc. > > From: Todd W Lainhart <[email protected]> > To: Barry Leiba <[email protected]> > Cc: "<[email protected]>" <[email protected]>; [email protected] > Sent: Wednesday, August 7, 2013 6:40 AM > Subject: Re: [OAUTH-WG] What should happen to access tokens when the end user > credentials change > > Assuming of course that the AS was notified by the IdP (or could inquire from > same, say, during introspection) that something about the user's account had > changed - there's nothing in the protocol that speaks to that. > > Would anyone be surprised if the authorizations granted to the previous > confirmation of identity were now void? That seems like the simplest way to > handle it. > > > > > > > Todd Lainhart > Rational software > IBM Corporation > 550 King Street, Littleton, MA 01460-1250 > 1-978-899-4705 > 2-276-4705 (T/L) > [email protected] > > > > > > From: Barry Leiba <[email protected]> > To: Sergey Beryozkin <[email protected]>, > Cc: "<[email protected]>" <[email protected]> > Date: 08/06/2013 08:50 AM > Subject: Re: [OAUTH-WG] What should happen to access tokens when the > end user credentials change > Sent by: [email protected] > > > > > Suppose a given user has approved a client's grant request and that client > > is now working with the access token tied to the user's login name (or some > > other representation of that user's login credentials). > > > > What would be the recommended course of action when that user's credentials > > (example, the user's login name) change, as far as the existing access > > tokens tied to that user are concerned ? > > An interesting question. > > I think it's not the OAuth protocol's concern, but a document > describing operations and deployment might suggest what to do. > Groping here (I'm not a UI expert): > > I expect that some changes (and/or some reasons for changes) would > make no difference to the authorizations the user has approved. If I > change my username from "barryleiba" to "bigkahuna" because I want to > be cool, I would want my authorizations to persist. If I change my > password because I routinely change my password, I would want my > authorizations to persist. If I change my password because I think my > old password was compromised, I would want to review my authorizations > and make sure nothing untoward is there. Alternatively, I might just > want to invalidate all of them and re-establish them as needed > afterward. > > So it would probably be good for the system in question to ask me what > to do about the authorizations I've given out, and allow me to review > them and address them one by one, and/or make a blanket decision for > the lot. > > Maybe: > > Your password has been changed. > > Do you want to revoke authorizations you have approved? [YES / NO] > > Or maybe: > > Your password has been changed. > > Do you want to review authorizations you have approved? [YES / NO] > > -- > Barry > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
