Re: [OAUTH-WG] Lifetime of refresh token

Justin Richer <jricher@mit.edu> Fri, 28 August 2015 16:21 UTC

Return-Path: <jricher@mit.edu>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DEAD1B3120 for <oauth@ietfa.amsl.com>; Fri, 28 Aug 2015 09:21:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dD5ULLovn_nU for <oauth@ietfa.amsl.com>; Fri, 28 Aug 2015 09:20:57 -0700 (PDT)
Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09A101B30C0 for <oauth@ietf.org>; Fri, 28 Aug 2015 09:20:56 -0700 (PDT)
X-AuditID: 1209190c-f79296d000000622-84-55e08a66e1b2
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 16.64.01570.66A80E55; Fri, 28 Aug 2015 12:20:54 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id t7SGKsRH015922; Fri, 28 Aug 2015 12:20:54 -0400
Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t7SGKpOb001321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 28 Aug 2015 12:20:53 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_6752F4D6-1FDD-439A-8768-2B156F100B28"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Justin Richer <jricher@mit.edu>
In-Reply-To: <CAMbDefsu0XAQvCR2+ako4PbsoKeezLwgizJ4dVsKMAY_DXM_wA@mail.gmail.com>
Date: Fri, 28 Aug 2015 12:20:51 -0400
Message-Id: <F864A96B-1D38-4FCC-9694-4F581C3B2CA4@mit.edu>
References: <CAMbDefvdNNLHSMZEXDDOhukzha8G0WLb9j7f6qVXTrXaGCQxTQ@mail.gmail.com> <DE1DE335-FBEF-494A-97F0-BE0F9D4BABAA@ve7jtb.com> <C44C21E6-2559-4099-8B21-3544DE8965BD@lodderstedt.net> <CAMbDefsu0XAQvCR2+ako4PbsoKeezLwgizJ4dVsKMAY_DXM_wA@mail.gmail.com>
To: Donghwan Kim <flowersinthesand@gmail.com>
X-Mailer: Apple Mail (2.2104)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOKsWRmVeSWpSXmKPExsUixG6nopvW9SDU4Ol9C4sVC78wWpx8+4rN 4tWxpywOzB47Z91l91iy5CeTx7GeftYA5igum5TUnMyy1CJ9uwSujH0XEgr68yqWL+9lbWCc F9fFyMEhIWAicfGachcjJ5ApJnHh3nq2LkYuDiGBxUwSq+e0M0M4GxklVn/9ywjhPGSSeNf1 jwWkhVkgQWLZ0emsIDavgJ7Eq1uXwWxhAUOJ0xtmMoLYbAKqEtPXtDCBbOMUCJRYdDsFJMwC FP704g87SJhZIF7i6UEVEJNXwEpiX5cTxKZ/jBLHFy1mBykXEdCVeHPpNivEobISu38/YprA KDALyRGzkBwBEdeWWLbwNTOErSmxv3s5C6a4hkTnt4msCxjZVjHKpuRW6eYmZuYUpybrFicn 5uWlFuka6uVmluilppRuYgSFP6ckzw7GNweVDjEKcDAq8fBabLgfKsSaWFZcmXuIUZKDSUmU V67jQagQX1J+SmVGYnFGfFFpTmrxIUYJDmYlEd4QIaAcb0piZVVqUT5MSpqDRUmcd9MPvhAh gfTEktTs1NSC1CKYrAwHh5IE7xaQoYJFqempFWmZOSUIaSYOTpDhPEDDGTpBhhcXJOYWZ6ZD 5E8xKkqJ854AaRYASWSU5sH1wtLTK0ZxoFeEecNA2nmAqQ2u+xXQYCagwS/j74IMLklESEk1 MGbL/NhucfuNx6HuB1OflCx//PKcw/LlM2u21wTw9OlVe0wq/aBRzz/f/oZ85OEmIcUPk06U Jtcu/lLfvjnQ4ayTjO+prLrlosmrhKT3ve9688Hn5ZHb5s4BEk/zej8fTk70/r4hqHDfEodT IqfW5i4W5RT8VryqLCvszYK2Na6xXXKVEXNNfimxFGckGmoxFxUnAgDzRisyKgMAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/3hbWshBVwlnO2Z5ILZFK0MerZGU>
Cc: "<oauth@ietf.org>" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Lifetime of refresh token
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 28 Aug 2015 16:21:01 -0000

One viable method for detecting “inactivity for one month” would be to have a one month expiration on the refresh token, but reset that counter every time the refresh token is used to get a new access token. You can do this by manipulating the expiration of the token object itself on your authorization server, or you can just throw away the old refresh token and create a new one with an expiration one month out. Each of these methods has its benefits and pitfalls.

 — Justin

> On Aug 28, 2015, at 10:21 AM, Donghwan Kim <flowersinthesand@gmail.com> wrote:
> 
> I'm sorry to introduce a common topic.
> 
> As John has suggested, I'm going to design that 
> 
> * An access token should be short lived e.g. 5 minutes (not to hit the AS to verify the token or 1 hour (to hit the AS to verify the token). I'm inclined to 5 minutes for stateless architecture of RSs.
> * A refresh token should have 1 month of expiration time by default. If it turns out that some access token expired, its refresh token should refresh the token. Then, so called persistent login can be implemented regardless of the form of authentication. Only if it fails for some reason e.g. token revocation or inactivity for 1 month, a user is logged out automatically and should log in again.
> * A refresh token should be able to be revoked somehow. With 5 minutes approach, it will invalidate only the refresh token (Yes the attacker can have 5 minutes at most), and with 1 hour approach, it will invalidate the refresh token as well as the corresponding access token.
> 
> Thanks,
> 
> -- Donghwan
> 
> On Fri, Aug 28, 2015 at 5:43 PM, Torsten Lodderstedt <torsten@lodderstedt.net <mailto:torsten@lodderstedt.net>> wrote:
> Refresh tokens are also used by public clients, e.g. native apps. OIDC allows to acquire a new id token from a refresh token as well. Note: this does not mean a fresh authentication but a refreshed id token containing the data of the original authentication transaction. 
> 
> Am 24. August 2015 17:08:21 MESZ, schrieb John Bradley <ve7jtb@ve7jtb.com <mailto:ve7jtb@ve7jtb.com>>:
> I think Nat’s diagram about the problems of doing pseudo authentication with OAuth is being taken out of context.
> 
> The refresh token dosen’t expire, it is revoked by the user or system.  In some cases refresh tokens are automatically revoked if the users session to the AS ends.  I think AOL typically revokes refresh tokens when sessions terminate.
> 
> OpenID Connect provides a separate id_token with a independent lifetime from the refresh token.  A client may keep a refresh token for a much longer time than the user has a login session with the AS.
> 
> Refresh tokens are typically used by confidential clients that are using a client secret in combination with the refresh token for getting a new access token.
> 
> By design access tokens should be short lived as the AS is expected to have a way of revoking refresh tokens but not access tokens.
> A access token that dosen't expire , and can’t be revoked is not a good idea.
> 
> John B.
> 
> 
>> On Aug 24, 2015, at 2:41 AM, Donghwan Kim <flowersinthesand@gmail.com <mailto:flowersinthesand@gmail.com>> wrote:
>> 
>> Hi,
>> 
>> According to Figure 2 from http://tools.ietf.org/html/rfc6749#section-1.5 <http://tools.ietf.org/html/rfc6749#section-1.5>, refresh token can be used to refresh an expired access token without requesting resource owner to sign in again (uncomfortable experience). However, if it's true, isn't it that refresh token might be used to request a new access token even years later? and then isn't refresh token the same with access token which never expires?
>> 
>> I intended to use refresh token to implement persistent login by sending a refresh request before issued access token expires (expires_in runs out). But if refresh token works even if access token expired already, sending a refresh request on application start up would be enough.
>> 
>> So I'm not sure what I'm missing about refresh token as well as how to implement persistent login using it (you can regard authentication here pseudo-authentication illustrated in https://upload.wikimedia.org/wikipedia/commons/3/32/OpenIDvs.Pseudo-AuthenticationusingOAuth.svg <https://upload.wikimedia.org/wikipedia/commons/3/32/OpenIDvs.Pseudo-AuthenticationusingOAuth.svg>). What is the lifetime of refresh token?
>> 
>> Thanks,
>> 
>> -- Donghwan
>> _______________________________________________
>> 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 <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