Re: [OAUTH-WG] OAuth 1 Bridge Flow

Marius Scurtescu <mscurtescu@google.com> Tue, 04 May 2010 18:25 UTC

Return-Path: <mscurtescu@google.com>
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 6B89028C15D for <oauth@core3.amsl.com>; Tue, 4 May 2010 11:25:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.475
X-Spam-Level:
X-Spam-Status: No, score=-100.475 tagged_above=-999 required=5 tests=[AWL=-0.912, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100]
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 uwjIkQA4ZRq8 for <oauth@core3.amsl.com>; Tue, 4 May 2010 11:25:31 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id B6CAB3A659A for <oauth@ietf.org>; Tue, 4 May 2010 11:22:06 -0700 (PDT)
Received: from wpaz37.hot.corp.google.com (wpaz37.hot.corp.google.com [172.24.198.101]) by smtp-out.google.com with ESMTP id o44ILoDx004930 for <oauth@ietf.org>; Tue, 4 May 2010 11:21:51 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1272997311; bh=VuXb2HN1bfWeDw8HkGBZtN07Jjc=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=wthQLkMBH0q8ovhVfOGmdxvIhWgELXsCqu9Z4iuuUYee3/hzmDe9aWj3fCnMKaq1z aJfXOdVKJ2eoTdT/RyKqw==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=c3jUMNudAAsv5gU95bIJIjouSIutHjZLf/0dTbywoDuZXL7K8MBCm7OanVSr8Wur4 nHc1VqrBlxSdHFt/D1kKg==
Received: from pvc30 (pvc30.prod.google.com [10.241.209.158]) by wpaz37.hot.corp.google.com with ESMTP id o44ILngS019539 for <oauth@ietf.org>; Tue, 4 May 2010 11:21:49 -0700
Received: by pvc30 with SMTP id 30so412352pvc.41 for <oauth@ietf.org>; Tue, 04 May 2010 11:21:49 -0700 (PDT)
Received: by 10.140.251.19 with SMTP id y19mr4943651rvh.161.1272997309196; Tue, 04 May 2010 11:21:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.141.14.15 with HTTP; Tue, 4 May 2010 11:21:29 -0700 (PDT)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723439323D0AC6@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <AANLkTilxyiK3KXohJJNcY18zv4N3S_pI1WuHOPDI6ctE@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E723439323D0AC6@P3PW5EX1MB01.EX1.SECURESERVER.NET>
From: Marius Scurtescu <mscurtescu@google.com>
Date: Tue, 4 May 2010 11:21:29 -0700
Message-ID: <AANLkTikPl3QFyxJoNYYf641ZfeeUMYC1VFYtyrqtBVee@mail.gmail.com>
To: Eran Hammer-Lahav <eran@hueniverse.com>
Content-Type: text/plain; charset=ISO-8859-1
X-System-Of-Record: true
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:25:35 -0000

On Tue, May 4, 2010 at 10:48 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
> Why a short lived 2.0 token? Why not provide an endpoint to exchange a 1.0 token with a 2.0 token with a refresh token?

Yes, we thought about this use case but wasn't sure about the right
implementation.

If an OAuth 2.0 refresh token is issued, then most likely the OAuth
1.0 access token should be revoked. This would be more like a
migration. Also, the OAuth 2.0 refresh token may need a corresponding
client secret, how would the client get that:
- assume this was provisioned offline
- assume OAuth 2.0 client secret = OAuth 1.0 consumer secret
- generate and send OAuth 2.0 client secret with the refresh token

The first approach seems the right one, and the second could be a special case.

I think a flag parameter is needed on the request to signal that a
migration should be performed (issue OAuth 2.0 refresh token and
revoke OAuth 1.0 access token) as opposed to just a short lived OAuth
2.0 access token request.

Thoughts?

Marius

>
> EHL
>
>> -----Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>> Of Marius Scurtescu
>> Sent: Tuesday, May 04, 2010 10:27 AM
>> To: OAuth WG
>> Subject: [OAUTH-WG] OAuth 1 Bridge Flow
>>
>> 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
>