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. To Marius: > Are the issued OAuth 2.0 access tokens short lived? Is "expires" a > 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. On May 4, 2010, at 4:03 PM, Allen Tom wrote: > 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 > > > On 5/4/10 11:46 AM, "Justin Richer" <jric...@mitre.org> 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@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
