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

Phil Hunt <phil.hunt@oracle.com> Mon, 12 August 2013 18:08 UTC

Return-Path: <phil.hunt@oracle.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3D1F21F9298; Mon, 12 Aug 2013 11:08:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.847
X-Spam-Level:
X-Spam-Status: No, score=-5.847 tagged_above=-999 required=5 tests=[AWL=0.751, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blQvD+yO6fxn; Mon, 12 Aug 2013 11:08:29 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 5591F21F9CF8; Mon, 12 Aug 2013 11:08:24 -0700 (PDT)
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7CI88XU013655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Aug 2013 18:08:09 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7CI83Yp008689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Aug 2013 18:08:03 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7CI82ca011382; Mon, 12 Aug 2013 18:08:02 GMT
Received: from [192.168.1.89] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 12 Aug 2013 11:08:02 -0700
Content-Type: multipart/alternative; boundary="Apple-Mail=_34B8953D-8092-4D68-8178-29A3445A9980"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Phil Hunt <phil.hunt@oracle.com>
In-Reply-To: <1375889079.85708.YahooMailNeo@web142805.mail.bf1.yahoo.com>
Date: Mon, 12 Aug 2013 20:08:00 +0200
Message-Id: <1E8ECD74-3356-4152-BC42-82BAB5F8F9B1@oracle.com>
References: <5200DD6C.3010003@gmail.com> <CAC4RtVAoSB5vQPiNB2JCBjJ8vOmvyKZSkAdwithzziXfjsku3w@mail.gmail.com> <OFDF319810.D5537EBC-ON85257BC0.004AB0BC-85257BC0.004B203C@us.ibm.com> <1375889079.85708.YahooMailNeo@web142805.mail.bf1.yahoo.com>
To: Bill Mills <wmills_92105@yahoo.com>
X-Mailer: Apple Mail (2.1508)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "<oauth@ietf.org>" <oauth@ietf.org>, Barry Leiba <barryleiba@computer.org>, "oauth-bounces@ietf.org" <oauth-bounces@ietf.org>
Subject: Re: [OAUTH-WG] What should happen to access tokens when the end user credentials change
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Aug 2013 18:08:56 -0000

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
phil.hunt@oracle.com





On 2013-08-07, at 5:24 PM, Bill Mills <wmills_92105@yahoo.com> 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 <lainhart@us.ibm.com>
> To: Barry Leiba <barryleiba@computer.org> 
> Cc: "<oauth@ietf.org>" <oauth@ietf.org>; oauth-bounces@ietf.org 
> 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)
> lainhart@us.ibm.com
> 
> 
> 
> 
> 
> From:        Barry Leiba <barryleiba@computer.org> 
> To:        Sergey Beryozkin <sberyozkin@gmail.com>, 
> Cc:        "<oauth@ietf.org>" <oauth@ietf.org> 
> 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:        oauth-bounces@ietf.org 
> 
> 
> 
> > 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
> OAuth@ietf.org
> 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