Re: [OAUTH-WG] OAuth 1 Bridge Flow
Justin Richer <jricher@mitre.org> Tue, 04 May 2010 18:56 UTC
Return-Path: <jricher@mitre.org>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9E2128C184 for <oauth@core3.amsl.com>; Tue, 4 May 2010 11:56:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.138
X-Spam-Level:
X-Spam-Status: No, score=-4.138 tagged_above=-999 required=5 tests=[AWL=-0.139, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9LrpqsuUl8B for <oauth@core3.amsl.com>; Tue, 4 May 2010 11:56:16 -0700 (PDT)
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id D8BC528C1D3 for <oauth@ietf.org>; Tue, 4 May 2010 11:46:51 -0700 (PDT)
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o44IkbmX027787 for <oauth@ietf.org>; Tue, 4 May 2010 14:46:37 -0400
Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o44Ikbs5027784; Tue, 4 May 2010 14:46:37 -0400
Received: from [129.83.50.65] (129.83.50.65) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server id 8.2.213.0; Tue, 4 May 2010 14:46:37 -0400
From: Justin Richer <jricher@mitre.org>
To: Marius Scurtescu <mscurtescu@google.com>
In-Reply-To: <AANLkTilxyiK3KXohJJNcY18zv4N3S_pI1WuHOPDI6ctE@mail.gmail.com>
References: <AANLkTilxyiK3KXohJJNcY18zv4N3S_pI1WuHOPDI6ctE@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 04 May 2010 14:46:36 -0400
Message-ID: <1272998796.6288.55.camel@localhost.localdomain>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3
Content-Transfer-Encoding: 7bit
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth 1 Bridge Flow
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 04 May 2010 18:56:17 -0000
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
- Re: [OAUTH-WG] OAuth 1 Bridge Flow Justin Richer
- Re: [OAUTH-WG] OAuth 1 Bridge Flow Allen Tom
- [OAUTH-WG] OAuth 1 Bridge Flow Marius Scurtescu
- Re: [OAUTH-WG] OAuth 1 Bridge Flow Eran Hammer-Lahav
- Re: [OAUTH-WG] OAuth 1 Bridge Flow Luke Shepard
- Re: [OAUTH-WG] OAuth 1 Bridge Flow Marius Scurtescu
- Re: [OAUTH-WG] OAuth 1 Bridge Flow Marius Scurtescu
- Re: [OAUTH-WG] OAuth 1 Bridge Flow Foiles, Doug
- Re: [OAUTH-WG] OAuth 1 Bridge Flow Luke Shepard
- Re: [OAUTH-WG] OAuth 1 Bridge Flow Luke Shepard