Re: [OAUTH-WG] Lifetime of refresh token

John Bradley <ve7jtb@ve7jtb.com> Mon, 24 August 2015 15:08 UTC

Return-Path: <ve7jtb@ve7jtb.com>
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 16A2D1A1A82 for <oauth@ietfa.amsl.com>; Mon, 24 Aug 2015 08:08:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 Q8kiGlDUhNZi for <oauth@ietfa.amsl.com>; Mon, 24 Aug 2015 08:08:41 -0700 (PDT)
Received: from mail-qk0-f180.google.com (mail-qk0-f180.google.com [209.85.220.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7881D1A0197 for <oauth@ietf.org>; Mon, 24 Aug 2015 08:08:40 -0700 (PDT)
Received: by qkbm65 with SMTP id m65so70429089qkb.2 for <oauth@ietf.org>; Mon, 24 Aug 2015 08:08:39 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=Xg1wbhUeFDsVrXc/2kpt2kST/ThKnBUZiiCL2zulIXc=; b=LhKaCiQwpggtdo0Vq9k2wlIjd+7rkNcqh3X2LLoh96cMcBwBwvjVFcbn7PbTQ/129C njXiEoHKle7eRyJLjMpbWW66frVKPzPLWf90Z29Mf6R0HQ/WQN0m65e5ELaU9GLVqMiE rstHHt3Gezr+MEfKOBM1s3W+1AgGiohMKYt+zw3kLHiqAq17AgxSBOBYSUS226sEsPgB fRcgitDyNgZxZJi3dEgVbR8qMeYiJXETUXPeNRizNVLGb9Ysd3uXL5Yh0Bx7qbdABUh9 /7Mk/MPBUcqO8OZzZBgqWFB26zfoCTHJwoLw5Gzu65w8UzEGV+D8jBTveql5qgv9C5IV Y72Q==
X-Gm-Message-State: ALoCoQlmEoL9JdH6lPQ6WxkFChH22NrZFJkGljZfLrLZKu/ZHSa5NBKB8Meca58/JY/TVoV2Zs+Z
X-Received: by 10.55.197.82 with SMTP id p79mr2986804qki.5.1440428919635; Mon, 24 Aug 2015 08:08:39 -0700 (PDT)
Received: from [192.168.1.41] (186-79-69-78.baf.movistar.cl. [186.79.69.78]) by smtp.gmail.com with ESMTPSA id 124sm11313478qht.14.2015.08.24.08.08.34 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 24 Aug 2015 08:08:38 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_4F6BC506-C322-4C97-BBA2-26E91E5540EE"; protocol="application/pkcs7-signature"; micalg="sha1"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <CAMbDefvdNNLHSMZEXDDOhukzha8G0WLb9j7f6qVXTrXaGCQxTQ@mail.gmail.com>
Date: Mon, 24 Aug 2015 12:08:21 -0300
Message-Id: <DE1DE335-FBEF-494A-97F0-BE0F9D4BABAA@ve7jtb.com>
References: <CAMbDefvdNNLHSMZEXDDOhukzha8G0WLb9j7f6qVXTrXaGCQxTQ@mail.gmail.com>
To: Donghwan Kim <flowersinthesand@gmail.com>
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/eXYz0pnoiQmoUnJv8zO1gUPxvqg>
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: Mon, 24 Aug 2015 15:08:50 -0000

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