The bridge flow was meant to be used in a mixed OAuth 1 and OAuth 2 environment, it allows the consumer to obtain a token using signatures and then access protected resources with no signatures. Now that signatures are re-introduced in OAuth 2 I don't think there is a need for such an approach.
That being said, migration can be done very similarly, differences from the bridge flow: - an OAuth 2 refresh token is also returned - optionally the OAuth 1 token is revoked Such a migration flow would allow a consumer/client that has OAuth 1 access tokens saved for its users to convert all of them to OAuth 2 refresh tokens without involving the users. Marius On Thu, Jul 8, 2010 at 4:05 AM, Stefanie Dronia <[email protected]> wrote: > Hi, > > > > I took a look at the OAuth 1 Bridge Flow suggested by Marius, the thread > "OAuth 1 Bridge Flow" and had some thoughts: > > > > I do not really see the necessity for such a flow. > > First of all, all participating parties have to be modified and rolled out: > > - the consumer's application to support (at least) the bridge flow (and > OAuth 2 [1]), > > - the authz server to provide OAuth 2 and additionally the bridge flow and > > - the resource server to handle OAuth2. > > Then, sometime later, when at least the authz server doesn't support OAuth 1 > anymore, the client application and the resource server should be cleared up > - no more OAuth 1, only OAuth 2. Again a new version to roll out. > > > > The only (small) benefit I see, is that the user will not be asked for > authorization again. > > But is it worth it to develop, implement and roll out a Bridge Flow? I do > not think so - too much expense for a small user interaction. > > Better: directly go to OAuth 2, when it is needed. > > > > The other thing I'm missing, is how to migrate completely to OAuth 2 after > performing the bridge flow. Issuing a refresh token in the response seems > necessary. But this issue was still mentioned (but not solved) in the thread > "OAuth 1 Bridge Flow" by Eran. > > > > > > Thanks, > > Steffi > > > > [1] if OAuth 2 will not be supported, a new modified client has to be rolled > out at the latest, the resource server doesn't support OAuth 1 anymore. > > > > -------- Original-Nachricht -------- > Datum: Tue, 6 Jul 2010 21:54:16 -0700 > Von: Marius Scurtescu <[email protected]> > An: Rob Richards <[email protected]> > CC: "[email protected]" <[email protected]> > Betreff: Re: [OAUTH-WG] Versioning > > On Sat, Jul 3, 2010 at 3:27 AM, Rob Richards <[email protected]> > wrote: >> Eran Hammer-Lahav wrote: >>> >>> Hi Rob, >>> >>> I agree with you that a migration spec is important - please write one. >>> >> >> Like I didn't see that coming :) > > I would like to help with this migration spec. Is this a good starting > point: > http://www.ietf.org/mail-archive/web/oauth/current/msg02300.html > > Or, you had something else in mind? > > Marius > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > > -- > GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
