Re: [OAUTH-WG] Access token timeout

Guangqing Deng <dgq2011@gmail.com> Tue, 21 August 2012 07:14 UTC

Return-Path: <dgq2011@gmail.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 6087921F8567 for <oauth@ietfa.amsl.com>; Tue, 21 Aug 2012 00:14:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.615
X-Spam-Level:
X-Spam-Status: No, score=-1.615 tagged_above=-999 required=5 tests=[AWL=1.983, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id se9t55uVGGet for <oauth@ietfa.amsl.com>; Tue, 21 Aug 2012 00:14:34 -0700 (PDT)
Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8A55321F8565 for <oauth@ietf.org>; Tue, 21 Aug 2012 00:14:34 -0700 (PDT)
Received: by ggnh4 with SMTP id h4so6212732ggn.31 for <oauth@ietf.org>; Tue, 21 Aug 2012 00:14:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=euNFK6wHF1mAtVJJIZdvtYCMykqgCB4eyEGgr80OqJ0=; b=qTDHAwNnDjPV4yf7ufVdwPXRp383vlQCxHukn0IuItozdpz+yhqz9oU6umC3NUPSWg 6rYyJKTRxDFQnBX/ATDpdtwGx9LcJlb2quMn0m0F/ydzJMGExFLAVL7MA+4mcGD32+LT qtOJOQtCKldhQUveNvb9BSWTLpwU0RWJJKQnnJcubxWaXSbLI9C4HmAJh8CszXAoILN0 Vyb1zk5pfaaVlJKPjE4th7ufkUoxrst8V8OycEUCZdco59d2wKJp6BWfYPY+C52zAASZ Z5UoTfHNClSPoVcuyR3e8hCSeCNUK/CtY/DjfD2158++xOjglQWToLDpOShKH/HrhTk4 y+HQ==
MIME-Version: 1.0
Received: by 10.50.88.167 with SMTP id bh7mr12411529igb.69.1345533273590; Tue, 21 Aug 2012 00:14:33 -0700 (PDT)
Received: by 10.64.52.68 with HTTP; Tue, 21 Aug 2012 00:14:33 -0700 (PDT)
In-Reply-To: <8E82B87D-B819-462A-8546-6E20CA3B48CA@ve7jtb.com>
References: <CAP279Lxk5+=2B3cFLzS=teRYu2qWbg9Ny263pfDpBRueC7pF+A@mail.gmail.com> <1345397735.4226.YahooMailNeo@web31809.mail.mud.yahoo.com> <8E82B87D-B819-462A-8546-6E20CA3B48CA@ve7jtb.com>
Date: Tue, 21 Aug 2012 15:14:33 +0800
Message-ID: <CAL4OH3SJKDCdLwhD2vksEh5Sd+0xEyiJrX+EyYnPJQUAeU5eXA@mail.gmail.com>
From: Guangqing Deng <dgq2011@gmail.com>
To: John Bradley <ve7jtb@ve7jtb.com>
Content-Type: multipart/alternative; boundary="e89a8f3ba245ce4b3104c7c160ed"
Cc: Jérôme LELEU <leleuj@gmail.com>, "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Access token timeout
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: Tue, 21 Aug 2012 07:14:35 -0000

Since both the “Client” and “Resource Server” don’t know the exact creation
time (namely the time the response was generated on “Authorization Server”,
just as mentioned in part 5.1 of OAUTH 2.0) of an access token, the exact
expiration time of an access token can’t be directly obtained by “Client”
and “Resource Server” in the presence of "expires_in". Usually, it doesn’t
matter to the “client”, for a hint of when the token will probably expire
is enough; however, the “Resource Server” must know the exact expiration
time of an access token and another scheme to obtain that time is needed.
So why not directly send the exact expiration time of an access token?


2012/8/20 John Bradley <ve7jtb@ve7jtb.com>

> A token can always expire in less than that time.
>
> I have seen deployments that use sliding windows and single use access
> tokens.   In those cases the "expires_in" is sent as a Max time before the
> token will expire.
>
> A client always needs to be prepared that a token will have been revoked
> or expired and fall back to using the refresh token, or reauthorize.
>
> John B.
>
> On 2012-08-19, at 1:35 PM, William Mills wrote:
>
> It's a hint to the client of when the token will probably expire.  There
> was a lot of discussion on what the right way to go was and there were
> several "camps" on the right strategy choice would be, but in the end a
> very simple solution was chosen.  Most folks agreed that having more than
> one way to go was not worth the complexity, so this single one was picked.
>
>   ------------------------------
> *From:* Jérôme LELEU <leleuj@gmail.com>
> *To:* oauth@ietf.org
> *Sent:* Sunday, August 19, 2012 1:25 AM
> *Subject:* [OAUTH-WG] Access token timeout
>
> Hi,
>
> I might be misunderstanding the OAuth 2.0 spec (part 5.1, "expires_in"
> property), but I understand that the timeout of the access token is a hard
> one (amount of time between creation and expiration).
>
> Am I right ?
>
> Can we have a multiple use timeout ? A sliding window timeout ? Or a
> combination of all ?
>
> Thanks.
> Best regards,
> Jérôme
>
>
> _______________________________________________
> 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
>
>


-- 
Guangqing Deng