Re: [OAUTH-WG] OAuth 1 Bridge Flow

"Foiles, Doug" <> Wed, 05 May 2010 14:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0C4BD3A68F0 for <>; Wed, 5 May 2010 07:14:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.596
X-Spam-Status: No, score=-3.596 tagged_above=-999 required=5 tests=[AWL=0.403, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EYHwjQ7fgBXD for <>; Wed, 5 May 2010 07:14:30 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EAF543A69A2 for <>; Wed, 5 May 2010 07:09:40 -0700 (PDT)
DomainKey-Signature: s=default;; c=nofws; q=dns; h=X-SBRS:X-IronPort-AV:Received:Received:X-MimeOLE: Content-class:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:Date:Message-ID: In-Reply-To:X-MS-Has-Attach:X-MS-TNEF-Correlator: Thread-Topic:Thread-Index:References:From:To:Return-Path: X-OriginalArrivalTime; b=CFUDp8W4ZBUTuZtCYjjJ8L7fBujYwZ7wYKtbWYtskXcRARGay0FOcxte e+tF7tPCzH1dAe+VSVIjjBE5Sc1oNgEW+Dg6OUp+78JNuLqtdvXBr33lO 95In7FHTprBPHyj;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=default; t=1273068568; x=1304604568; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; z=MIME-Version:=201.0|Content-Transfer-Encoding:=20base64 |Subject:=20RE:=20[OAUTH-WG]=20OAuth=201=20Bridge=20Flow |Date:=20Wed,=205=20May=202010=2007:09:24=20-0700 |Message-ID:=20<BE42DBBC1969B541915E30C5517382D90484C368@>|In-Reply-To:=20<C805F5EE.2DE8>|References:=20<1272998796.6288.55.c amel@localhost.localdomain>=20<C805F5EE.2DE86%atom@yahoo->|From:=20"Foiles,=20Doug"=20<Doug_Foiles@intuit.c om>|To:=20"Allen=20Tom"=20<>,=0D=0A=09" Justin=20Richer"=20<>,=0D=0A=09"Marius =20Scurtescu"=20<>,=0D=0A=09"OAuth =20WG"=20<>; bh=jZscqtgBuQs+xunQGCfjtn5F0K/l5Q3D3bYRDw9pg5Y=; b=XMQF9Dd3sfF6LKLOw0AE1Wlf+cDds5+cP0pHV7njQiOOwhKzCfgl3mdM zBtpT4ujBIOYo2yQiQnjifeR3hXVUuovgmX44rYhAWB95qMZRAV0lM3D3 61qO0XE7DlxdEEK;
X-SBRS: None
X-IronPort-AV: E=Sophos;i="4.52,333,1270450800"; d="scan'208";a="181441356"
Received: from ([]) by with ESMTP; 05 May 2010 07:09:25 -0700
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 May 2010 07:09:25 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Date: Wed, 05 May 2010 07:09:24 -0700
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [OAUTH-WG] OAuth 1 Bridge Flow
Thread-Index: Acrr3hO+SSKG8b2vd0mSA3+8duqBbgAfCUpw
References: <1272998796.6288.55.camel@localhost.localdomain> <>
From: "Foiles, Doug" <>
To: Allen Tom <>, Justin Richer <>, Marius Scurtescu <>, OAuth WG <>
X-OriginalArrivalTime: 05 May 2010 14:09:25.0215 (UTC) FILETIME=[9149A6F0:01CAEC5C]
Subject: Re: [OAUTH-WG] OAuth 1 Bridge Flow
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 05 May 2010 14:14:32 -0000

I would expect our OAuth 1.0 services to have support for OAuth 1.0 and 2.0 for some period.  I don't think we could expect all our clients to move to OAuth 2.0 at once.  This is an interesting idea that allows clients to be able to cut over to OAuth 2.0 without users having to re-authenticate/authorize.

Why not just transfer the remaining session lifetime to the new access token (or refresh token if requested).  I would expect the scope to be transferred as well.  I would want our users to authorize any extended period.

Could the need to replace the client secret just be left up to the authorization service?

Revoking the OAuth 1.0 token seems to fit the spirit of the use case.

-----Original Message-----
From: [] On Behalf Of Allen Tom
Sent: Tuesday, May 04, 2010 4:04 PM
To: Justin Richer; Marius Scurtescu; OAuth WG
Subject: Re: [OAUTH-WG] OAuth 1 Bridge Flow

Although we have not formally announced any plans to support OAuth2 yet, I
would expect that Yahoo would be able to simultaneously support both Oauth
1.0a and OAuth2 without requiring clients to upgrade their existing Oauth
1.0a credentials for OAuth2.

Note: Yahoo currently requires the Session Extension, so all of our Access
Tokens are valid for one hour. The OAuth2 Refresh Token is equivalent to the
Session Extension's "Auth Session Handle"


On 5/4/10 11:46 AM, "Justin Richer" <> wrote:

> Interesting work. So as each app upgrades its support from OAuth1 to
> OAuth2, it exchanges its old tokens for new ones once for each user,
> right? Then the app in question is effectively going to have to speak
> both flavors of OAuth to do this one-time upgrade. I always assumed that
> apps would just have to get new OAuth2 access tokens by going back to
> the user (since tokens are cheap), but I can definitely see value in
> there being a clean upgrade path, especially for wide deployments.
> Because the other side of things, what would it take an implementor to
> have a backwards-compatible system? Since the OAuth2 protocol is by
> design not backwards compatible (though the signature-based web flows
> are all the same spirit as 1.0a, all the parameter names are different),
> I'm thinking that one would need either parallel endpoints or a proxy of
> some kind that works almost like that which was proposed here, but on an
> ongoing basis. 
>  -- Justin
> On Tue, 2010-05-04 at 13:26 -0400, Marius Scurtescu wrote:
>> Hi,
>> I would like to suggest a flow, or endpoint, that is bridging OAuth 1
>> and OAuth 2. See the attachment.
>> The OAuth 1 Bridge Flow basically defines an endpoint where you can
>> place a signed OAuth 1 request and in response you receive a short
>> lived OAuth 2.0 access token. This flow can be used by clients that
>> have a long lived OAuth 1.0 access token and want to use a short lived
>> OAuth 2.0 access token to access protected resources.
>> Do you have a use case for a flow like this? If not exactly but close,
>> how can the flow be improved to cover your use case as well?
>> Feedback more than welcome.
>> Thanks,
>> Marius
> _______________________________________________
> OAuth mailing list

OAuth mailing list