Subject: [OAUTH-WG] OAuth 1 Bridge Flow

From: Marius Scurtescu <[email-masked]>
Date: Tue, 4 May 2010 10:26:44 -0700

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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 4 May 2010 10:48:51 -0700

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?

EHL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 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?
>

---

From: Luke Shepard <[email-masked]>
Date: Tue, 4 May 2010 11:03:12 -0700

That's a good idea.

FWIW we created a custom endpoint for this purpose - allows you to exchange Facebook sessions for OAuth 2.0 tokens. Documented here: http://developers.facebook.com/docs/guides/upgrade

On May 4, 2010, at 10:48 AM, Eran Hammer-Lahav wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 4 May 2010 11:21:29 -0700

> 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

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 4 May 2010 11:31:14 -0700

> FWIW we created a custom endpoint for this purpose - allows you to exchange Facebook sessions for OAuth 2.0 tokens. Documented here: http://developers.facebook.com/docs/guides/upgrade

Thanks for the pointer.

Are the issued OAuth 2.0 access tokens short lived? Is "expires" a
delta or an absolute time?

Marius

---

From: Justin Richer <[email-masked]>
Date: Tue, 4 May 2010 14:46:36 -0400

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

---

From: Allen Tom <[email-masked]>
Date: Tue, 04 May 2010 16:03:58 -0700

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"

Allen

---

From: "Foiles, Doug" <[email-masked]>
Date: Wed, 5 May 2010 07:09:24 -0700

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: [email-masked] [mailto:[email-masked]] 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

Allen

---

From: Luke Shepard <[email-masked]>
Date: Thu, 6 May 2010 22:39:42 -0700

Obviously if a service adopts OAuth 2.0, they should continue supporting their old method of login - Facebook will no doubt continue to support its old method of MD5 sigs for a long time, so as not to break apps in the wild.

But if a user has already authorized your app, and you WANT to use OAuth 2.0 but you have an old token, then you should be able to silently exchange an OAuth 1.0 token for an access token without asking the user for permission. That's the flow Marius proposed.

> delta or an absolute time?

Our access tokens, like our session keys, can be either short lived (1 hour) or long lived (basically infinite). In practice, though, we don't expect people to go to the effort of exchanging a short-lived token - after exchange, the new token has the same expiration as the original. It looks like we are using an absolute time when we should be doing a delta, good catch.

---

From: Luke Shepard <[email-masked]>
Date: Thu, 6 May 2010 22:43:12 -0700

> 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 authori…

Yeah. Facebook's access tokens are literally just wrapping the old session tokens, so the access token preserves all the original properties. I expect many services that upgrade will likely use a similar approach.