Subject: [OAUTH-WG] What should happen to access tokens when the end user credentials change

From: Sergey Beryozkin <[email-masked]>
Date: Tue, 06 Aug 2013 12:26:36 +0100

Hi

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 ?

I haven't seen anything specific in Security Considerations document.
Should the access tokens be simply refreshed internally, or invalidated, 
or is it nothing to do at all with OAuth2 (code flow), the fact the end 
user may change the login name ?

I wonder what the best practice is in this case

Thanks, Sergey

---

From: Barry Leiba <[email-masked]>
Date: Tue, 6 Aug 2013 14:47:03 +0200

> 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

---

From: Sergey Beryozkin <[email-masked]>
Date: Tue, 06 Aug 2013 15:37:06 +0100

Hi

thanks for your thoughts, comments below,
>      Do you want to review authorizations you have approved?  [YES / NO]

Letting the user to decide what has to happen to authorizations in such 
cases seems like a nice idea. It would probably be good if Security 
Considerations doc had some dedicated section, but either way I think I 
have my question answered :-)
Thanks, Sergey

---

From: Todd W Lainhart <[email-masked]>
Date: Wed, 7 Aug 2013 09:40:34 -0400

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-masked]

From:   Barry Leiba <[email-masked]>
To:     Sergey Beryozkin <[email-masked]>, 
Cc:     "<[email-masked]>" <[email-masked]>
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-masked]

> Suppose a given user has approved a client's grant request and that 
client
> What would be the recommended course of action when that user's 
credentials

An interesting question.

Maybe:

Or maybe:

--
Barry
_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Bill Mills <[email-masked]>
Date: Wed, 7 Aug 2013 08:24:39 -0700 (PDT)

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-masked]>
To: Barry Leiba <[email-masked]> 
Cc: "<[email-masked]>" <[email-masked]>; [email-masked] 
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

From:      
 Barry Leiba <[email-masked]> 
To:      
 Sergey Beryozkin <[email-masked]>,  
Cc:      
 "<[email-masked]>"
<[email-masked]> 
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-masked] 
________________________________

An interesting question.

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.

Maybe:

   Do you want to revoke authorizations you have approved?  [YES
/ NO]

Or maybe:

   Do you want to review authorizations you have approved?  [YES
/ NO]

---

From: Phil Hunt <[email-masked]>
Date: Mon, 12 Aug 2013 20:08:00 +0200

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-masked]

On 2013-08-07, at 5:24 PM, Bill Mills <[email-masked]> wrote:

> 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