IETF Logo Mail Archive

Re: [OAUTH-WG] Refresh Tokens

Anthony Nadalin <tonynad@microsoft.com> Thu, 11 August 2011 18:16 UTC

Return-Path: <tonynad@microsoft.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 B482921F8B29 for <oauth@ietfa.amsl.com>; Thu, 11 Aug 2011 11:16:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.466
X-Spam-Level:
X-Spam-Status: No, score=-7.466 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I27l9x9xJtGy for <oauth@ietfa.amsl.com>; Thu, 11 Aug 2011 11:16:09 -0700 (PDT)
Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id EA56B21F8B19 for <oauth@ietf.org>; Thu, 11 Aug 2011 11:16:08 -0700 (PDT)
Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 11 Aug 2011 11:16:36 -0700
Received: from VA3EHSOBE008.bigfish.com (157.54.51.114) by mail.microsoft.com (157.54.80.25) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 11 Aug 2011 11:16:35 -0700
Received: from mail130-va3-R.bigfish.com (10.7.14.240) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.22; Thu, 11 Aug 2011 18:15:42 +0000
Received: from mail130-va3 (localhost.localdomain [127.0.0.1]) by mail130-va3-R.bigfish.com (Postfix) with ESMTP id B725313D00FF for <oauth@ietf.org.FOPE.CONNECTOR.OVERRIDE>; Thu, 11 Aug 2011 18:15:42 +0000 (UTC)
X-SpamScore: -26
X-BigFish: PS-26(zz9371K936eKc85fh98dKzz1202h1082kzz1033IL8275bh8275dhz31h2a8h668h839h61h)
X-Spam-TCS-SCL: 0:0
X-Forefront-Antispam-Report: CIP:207.46.4.139; KIP:(null); UIP:(null); IPV:SKI; H:SN2PRD0302HT009.namprd03.prod.outlook.com; R:internal; EFV:INT
Received-SPF: softfail (mail130-va3: transitioning domain of microsoft.com does not designate 207.46.4.139 as permitted sender) client-ip=207.46.4.139; envelope-from=tonynad@microsoft.com; helo=SN2PRD0302HT009.namprd03.prod.outlook.com ; .outlook.com ;
Received: from mail130-va3 (localhost.localdomain [127.0.0.1]) by mail130-va3 (MessageSwitch) id 1313086534706771_16545; Thu, 11 Aug 2011 18:15:34 +0000 (UTC)
Received: from VA3EHSMHS026.bigfish.com (unknown [10.7.14.251]) by mail130-va3.bigfish.com (Postfix) with ESMTP id 9E30C101004B; Thu, 11 Aug 2011 18:15:34 +0000 (UTC)
Received: from SN2PRD0302HT009.namprd03.prod.outlook.com (207.46.4.139) by VA3EHSMHS026.bigfish.com (10.7.99.36) with Microsoft SMTP Server (TLS) id 14.1.225.22; Thu, 11 Aug 2011 18:15:30 +0000
Received: from SN2PRD0302MB137.namprd03.prod.outlook.com ([169.254.5.250]) by SN2PRD0302HT009.namprd03.prod.outlook.com ([10.27.90.204]) with mapi id 14.01.0225.064; Thu, 11 Aug 2011 18:15:29 +0000
From: Anthony Nadalin <tonynad@microsoft.com>
To: Dick Hardt <dick.hardt@gmail.com>
Thread-Topic: [OAUTH-WG] Refresh Tokens
Thread-Index: AcxYTQ8Url5GUfgWROGRaafg4jY5WAAAisuAAACFmiA=
Date: Thu, 11 Aug 2011 18:15:28 +0000
Message-ID: <B26C1EF377CB694EAB6BDDC8E624B6E723B89BDE@SN2PRD0302MB137.namprd03.prod.outlook.com>
References: <B26C1EF377CB694EAB6BDDC8E624B6E723B89B68@SN2PRD0302MB137.namprd03.prod.outlook.com> <D6EA09FB-21A1-40E8-93FF-5BB5E974D06B@gmail.com>
In-Reply-To: <D6EA09FB-21A1-40E8-93FF-5BB5E974D06B@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [131.107.0.76]
Content-Type: multipart/alternative; boundary="_000_B26C1EF377CB694EAB6BDDC8E624B6E723B89BDESN2PRD0302MB137_"
MIME-Version: 1.0
X-OrganizationHeadersPreserved: SN2PRD0302HT009.namprd03.prod.outlook.com
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%GMAIL.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-OriginatorOrg: microsoft.com
X-CrossPremisesHeadersPromoted: TK5EX14HUBC104.redmond.corp.microsoft.com
X-CrossPremisesHeadersFiltered: TK5EX14HUBC104.redmond.corp.microsoft.com
Cc: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Refresh Tokens
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: Thu, 11 Aug 2011 18:16:09 -0000

Many reasons, but none are explained in the specification

From: Dick Hardt [mailto:dick.hardt@gmail.com]
Sent: Thursday, August 11, 2011 10:51 AM
To: Anthony Nadalin
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens

My recollection of refresh tokens was for security and revocation.

security: By having a short lived access token, a compromised access token would limit the time an attacker would have access

revocation: if the access token is self contained, authorization can be revoked by not issuing new access tokens. A resource does not need to query the authorization server to see if the access token is valid.This simplifies access token validation and makes it easier to scale and support multiple authorization servers.  There is a window of time when an access token is valid, but authorization is revoked.



On 2011-08-11, at 10:40 AM, Anthony Nadalin wrote:


Nowhere in the specification is there explanation for refresh tokens, The reason that the Refresh token was introduced was for anonymity. The scenario is that a client asks the user for access. The user wants to grant the access but not tell the client the user's identity. By issuing the refresh token as an 'identifier' for the user (as well as other context data like the resource) it's possible now to let the client get access without revealing anything about the user. Recommend that the above explanation be included so developers understand why the refresh tokens are there.
_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth

v2.23.0 | Report a Bug | By Email