Re: [OAUTH-WG] Lifetime of refresh token

Torsten Lodderstedt <torsten@lodderstedt.net> Fri, 28 August 2015 08:44 UTC

Return-Path: <torsten@lodderstedt.net>
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 8636C1B2AEC for <oauth@ietfa.amsl.com>; Fri, 28 Aug 2015 01:44:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.251
X-Spam-Level:
X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 8lIwY-IdB7yD for <oauth@ietfa.amsl.com>; Fri, 28 Aug 2015 01:43:58 -0700 (PDT)
Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 275A41AD08F for <oauth@ietf.org>; Fri, 28 Aug 2015 01:43:57 -0700 (PDT)
Received: from [80.187.101.24] (helo=[10.23.196.190]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-SHA:256) (Exim 4.84) (envelope-from <torsten@lodderstedt.net>) id 1ZVFGH-0004au-B2; Fri, 28 Aug 2015 10:43:49 +0200
User-Agent: K-9 Mail for Android
In-Reply-To: <DE1DE335-FBEF-494A-97F0-BE0F9D4BABAA@ve7jtb.com>
References: <CAMbDefvdNNLHSMZEXDDOhukzha8G0WLb9j7f6qVXTrXaGCQxTQ@mail.gmail.com> <DE1DE335-FBEF-494A-97F0-BE0F9D4BABAA@ve7jtb.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----GF6UIMOD2AEB89J6GMCQ4SFQNQBS7G"
Content-Transfer-Encoding: 8bit
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Date: Fri, 28 Aug 2015 10:43:52 +0200
To: John Bradley <ve7jtb@ve7jtb.com>, Donghwan Kim <flowersinthesand@gmail.com>
Message-ID: <C44C21E6-2559-4099-8B21-3544DE8965BD@lodderstedt.net>
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/mI0LQqm4J40JZtkIOl6QP2xVzEE>
Cc: 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 08:44:01 -0000

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