“redirect uri” errors and Installed Application 1

A lot of us get the “redirect uri” error while developing on localhost, the easiest solution to this has been to create a Client ID for native application and bypass the issue all together.

About a month ago a user of the site Andrew Jennings left me a comment, I have contacted him and asked him if I could share it with you.

Hi Linda,

A lot of your readers – and I – are getting “redirect uri” errors. The common solution theme is to use Installed Application instead of Web Application when creating the client id’s in the developer console. There’s more to this, I thought I might share with you and your readers.

If you use the native Drive SDK, and your code is based on the infamous sample code Google provides, then, your code is probably using the GoogleWebAuthorizationBroker.AuthorizeAsync() method, which takes several arguments. The first argument takes a ClientSecrets object, which is nothing more than a wrapper which exposes a 2-element array of strings, which are read from the filestream based on the JSON file you feed it. The code behind the Secrets() method simply strips out everything except the client id and secret, and returns a 2-element string array. That is why you could just as easily replace Secrets() with a 2-element array containing the client id and secret, if you have your own implementation for handling these details.

Note the glaring problem: Nobody’s providing the redirect URI and port. You could configure your console’s client ID details by not using localhost and instead use some public domain (eg, http://hello.world.com/service/authorize.asp), but all of that is ignored when you use the native Drive SDK. If instead you use the Installed Application option to create your client id and secret, the URL is assumed to be that odd string, which is a fancy way of using localhost.

Now, if you wanted to use the REST API, and not the Google Drive SDK, you’ll need to roll up your sleeves. You won’t be using the GoogleWebAuthorizationBroker.AuthorizeAsync() anymore; rather, you’ll be stuffing HTTP headers and POST fields with the client id, secret, tokens, and several other options — including the redirect URI!

And as it turns out, you can create a Web Application-based client id *and* use the REST api and everything works fine – no redirect errors! This I verified, and have no problems whatever. (Well, I do – but not authorization errors…)

This doesn’t explain why redirect errors are happening, except to say that it’s probably a bug, or, that the Google native SDK was not intended to be used with client id’s associated with Web Applications. You’d think with all the gazillions of websites in Google search databases, they could have left room to mention this “tiny” detail in their documentation.

So therein lies the rules:

(1) If you use Installed Application for your Client Id, you MUST use the native Drive SDK, because, the Drive SDK will automatically plugin in “urn:ietf:wg:oauth:2.0:oob” for you, which is apparently a “localhost” synonym; whereas the REST API absolutely, unequivocally, requires you to provide a redirect URI and that cannot be provided to the SDK – it just doesn’t accept it.

(1a) Conversely, if you are planning to use the Drive SDK, you MUST feed it a Client Id that is associated with a Installed Application.

(2) If you use Web Applications for your Client Id, you MUST use the REST API, because the client ID you get is configured somewhere in the Google backbone to expect that you will soon accompany it with a redirect URI. You cannot use the native Drive SDK, because you don’t get a chance to provide the redirect uri, and the client Id is associated with a process that expects a redirect uri to be provided – and yet can’t be provided.

(2a) Conversely, if you are using the REST API, you MUST feed it a Client Id that is associated with an Web Application.

I haven’t played around with the Secrets argument (the 2-element string array). When I get time (or maybe you or your readers have time) add a 3rd (and maybe 4th?) element containing domain and redirect uri, in hopes that it might be read by the AuthorizeAsync() method. Otherwise, the name of the class should suggest that it’s only to be used with Web Apps (because of the word “Web” in the name of the class). Oops… as we know, Web Application client id’s don’t work – must be Installed Application

Installed Application ==> Drive SDK

Drive SDK ==> Installed Application

Web Application REST API

REST API Web Application

Conclusion

I would like to personally thank Andrew for his wonderful write up on this issue.