For token migration from Oauth 1 to 2 are we ever really going to need to do that silently for a user in a client? It's reasonable when the user gets a new client install that supports a new protocol for them to have to re-authenticate. Where I see this happening is in a big server migration where you're integrating with somone like Google IMAP and you already have a huge store of tokens for IMAP and you want yo convert to Oauth 2 but you don't want to prompt all your users.
Do I have this right? > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] > On Behalf Of Rob Richards > Sent: Friday, July 16, 2010 2:34 AM > To: Marius Scurtescu > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Versioning > > > On 7/14/10 6:33 PM, Marius Scurtescu wrote: > > On Wed, Jul 14, 2010 at 11:46 AM, Rob > Richards<rricha...@cdatazone.org> wrote: > >> Finally getting a chance to catchup and respond to this thread. > >> > >> Marius Scurtescu wrote: > >>> See comments bellow... > >>> > >>> > >>> On Fri, Jul 9, 2010 at 4:27 AM, Stefanie > Dronia<sdro...@gmx.de> wrote: > >>> > >>>> Hallo Marius, > >>>> > >>>> thanks for your statement. > >>>> Your idea of a migration flow is quite good and necessary. > >>>> > >>>> But I still doubt, if the work and effort should be > investigated to > >>>> spare the user from some interaction (authentication and > user consent). > >>>> > >>> It all depends for how many users does the client have > OAuth 1 tokens. > >>> Asking users to re-approve will confuse them and I guess > many will > >>> not do it, > >>> > >> I think the user should not be excluded from this interaction and > >> should be required to re-approve. IMO they should be > involved as its > >> also informational to know that the client they have previously > >> authorized is now requesting new credentials under a different > >> security scheme. The user should be the one to decide > whether or not they want to allow this. > > Why would you re-prompt the user? The only thing that > really changes > > is the underlying protocol, something most end users are not made > > aware of. How would the new approval page be any different from the > > initial one? The user granted a client access to some of its > > resources, that stays the same. If the authorization server > makes it > > explicit on the approval page that OAuth 1 is used, then yes, a > > re-approval is needed, but I don't think this normally happens. > > > > > >> When it comes right down to it the only concrete thing I > can think of > >> when migrating from 1.0 to 2.0 is the need to determine > which version > >> is being used at the resource endpoint. For most clients > moving from > >> 1.0 to 2.0 they will most likely just create the next version of > >> their client/app with 2.0 support and completely drop 1.0 support > >> rather than going through any migration flow. > > That depends on the client. If the client is a web site that has > > several thousand users, and it stores OAuth 1 access tokens for all > > these users, then migration totally makes sense. If the > client is an > > iPhone app with only one user, then maybe you are right. > Even in this > > case, I am sure the app would prefer not to annoy the user and just > > silently move to OAuth 2. If you are the app developer and your app > > has a large install base, would you risk losing even a small > > percentage of those users simply because you presented them with a > > confusing approval page? > > > > > > > As a user I would say yes, I want to be re-prompted or at > least explicitly request the migration of my tokens rather > than having something done silently, behind the scenes and > unbeknownst to me. The underlying protocol has changed, > whether or not I know it, and for all purposes could be the > most insure protocol out there. When something this > fundamental changes, I would want to have to re-authorize the > application because I could just as easily at this point decline. > Perhaps I went and read the changelog, the change was made > known on the site, or someone discovered the change and made > it public. As you can probably tell I lean way more towards > the side of the user and personally think it is more > responsible of the app or web site in question here to > require the re-authorization and risk losing some users (if > that is the case then clearly the application is not worth > the users time in the first place) than to silently change > the protocol on me. > > Rob > > _______________________________________________ > 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
