Return-Path: 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 401A021F86DF for ; Tue, 21 Aug 2012 08:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.581 X-Spam-Level: X-Spam-Status: No, score=-6.581 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 cHcm9B+iQwFT for ; Tue, 21 Aug 2012 08:01:45 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 290A921F86B8 for ; Tue, 21 Aug 2012 08:01:45 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9DC4121B15BE; Tue, 21 Aug 2012 11:01:44 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 7BFC621B0C80; Tue, 21 Aug 2012 11:01:44 -0400 (EDT) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 21 Aug 2012 11:01:44 -0400 Message-ID: <5033A27D.8000603@mitre.org> Date: Tue, 21 Aug 2012 11:00:13 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Guangqing Deng References: <1345397735.4226.YahooMailNeo@web31809.mail.mud.yahoo.com> <8E82B87D-B819-462A-8546-6E20CA3B48CA@ve7jtb.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090005060101070103010700" X-Originating-IP: [129.83.31.58] Cc: "oauth@ietf.org" , =?ISO-8859-1?Q?J=E9r=F4me_LELEU?= Subject: Re: [OAUTH-WG] Access token timeout X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 15:01:46 -0000 --------------090005060101070103010700 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Forgot to address this bit directly: > So why not directly send the exact expiration time of an access token? > As Bill said, this question of "expires_in" vs. "expires_at" was discussed in depth on the list. The truth is, "expires at" is susceptible to clock skew between the server and client (or RS and AS), and this was shown to be a real-world problem with both OAuth1 and OpenID 2.0 timestamps. (I would imagine it's so with other systems as well.) In Oauth1, tokens could expire on the client without the client ever knowing what just happened. With this hint, a smart client can try to refresh their token ahead of time if the timestamp is getting close. Dumb clients still get to ignore it and just respond to an expired token and revoked token in the same way, and everyone's happy. -- Justin > > 2012/8/20 John Bradley > > > 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 > >> *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 > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------090005060101070103010700 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
Forgot to address this bit directly:

So why not directly send the exact expiration time of an access token?


As Bill said, this question of "expires_in" vs. "expires_at" was discussed in depth on the list. The truth is, "expires at" is susceptible to clock skew between the server and client (or RS and AS), and this was shown to be a real-world problem with both OAuth1 and OpenID 2.0 timestamps. (I would imagine it's so with other systems as well.)

In Oauth1, tokens could expire on the client without the client ever knowing what just happened. With this hint, a smart client can try to refresh their token ahead of time if the timestamp is getting close. Dumb clients still get to ignore it and just respond to an expired token and revoked token in the same way, and everyone's happy.

 -- Justin


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



_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--------------090005060101070103010700--