text: July 9, 2015 in Blog tagged C# .net / Google Developers Console / Google Oauth2 / Tips & Tricks by Linda Lawton
  Please Share
  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.
  Please Share
  Related posts:
  Google Calendar OAuth2 – PHP
  Google Authentication with CURL
  Google Analytics OAuth2 – PHP
  Google Developer Console Oauth2 credentials
  About Linda Lawton
  My name is Linda Lawton I have more than 20 years experience working as an application developer and a database expert. I have also been working with Google APIs since 2012 and I have been contributing to the Google .Net client library since 2013. In 2013 I became a a Google Developer Experts for Google Analytics.
  View all posts by Linda Lawton →
  Leave a comment Cancel reply
  Your email address will not be published. Required fields are marked *
  Comment
  Name *
  Email *
  Website
  Save my name, email, and website in this browser for the next time I comment.
  Sign me up for the newsletter! max one a month
  Δ
  This site uses Akismet to reduce spam. Learn how your comment data is processed.
  One thought on ““redirect uri” errors and Installed Application”
  Reply ↓
  Steve April 4, 2019 at 11:38 am
  Thanks a tonne for this, given how poor the documentation is for Google API stuff, this was incredibly helpful. I think the only difference now was that you select ‘Other’ for the type of application.
  Post navigation
  ← TARGIT Google Analytics SSIS
  Google+ Photo shutdown →
  Search for:
  YouTube
  For more help try My YouTube channel
  Like what I do? Donate
  Did I help you? Did one of my tutorials save you sometime? You can say thank you by buying me a cup of coffee, I go though a lot of it.
  Consulting Service
  I offer a per hour consulting service if you have problems with your project or would just like some information on things you need to take into account during your development process. Contact me here
  [wp_ad_camp_1]
  Consulting service
  If you need assistance with your project I offer a consulting service, but I don't have the time to help everyone. If you need me I charge a start up fee and have an hourly rate. you can contact me Linda Lawton Consulting
  Sign up to my RSS feed!
  All Tutorials
  All Blog posts
  all C#
  all PHP
  About
  My name is Linda Lawton I have been working with the Google APIs since 2012. I started Daimto.com in 2013 when I found a lack of tutorials to help developers access the Google APIs using .net and PHP. In March 2014 I was recognized by Google as a Google Developers expert for my work.
  · © 2022 Daimto · Powered by · Designed with the Customizr theme ·
  This website uses cookies to improve your experience. We'll assume you're ok with thisAccept
  Privacy & Cookies Policy
  Close
  Privacy Overview
  This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
  Necessary
  Necessary
  Always Enabled
  Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
  Non-necessary
  Non-necessary
  Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.