4

I'm developing a desktop application that will integrate with one or several of the Google APIs. I've done a lot of reading on the subject of OAuth 2.0, and my impression is that the spec says the client_secret should not be required for desktop applications, where it cannot actually be kept secret. Anybody with a decompiler or the ability to inspect web requests can figure out what the secret is.

However, per https://developers.google.com/youtube/v3/guides/auth/installed-apps I attempted to send my request to receive an access and refresh token, but received the following 400 Bad Request:

{
  "error": "invalid_request",
  "error_description": "client_secret is missing."
}

Obviously, I also tried it by adding and sending the client_secret, which worked fine.

So, that being the case:

  1. Is this a bug in the API? Should this field actually not be required?
  2. If it is not a bug, does that mean the only proper solution is to set up an intermediary authentication server that passes along these authentication requests?

The latter seems like a ridiculous requirement to use a REST API. Though, if there are any services or projects already out there that solve this problem, I'd be much obliged to know about them. I could write something myself, but I don't want to be forced to stand up a server, set up SSL, and then write a server application for these requests.

Some of the research I did indeed took me to this post: client secret in OAuth 2.0

However, this doesn't specifically mention the API I'm attempting to use. It also doesn't cover too many workarounds. It does seem to resonate with the thoughts I've placed here, though.

Community
  • 1
  • 1
Jyosua
  • 648
  • 1
  • 6
  • 18
  • To my knowledge Googles authentication server requires that you send client secret when exchanging the authentication code for the refresh token. Once you have the refresh token you don't need to send it. – Linda Lawton - DaImTo Jan 19 '16 at 07:54
  • So, in order to keep the client secret actually secret, it looks like I'm going to have to set up a webserver. – Jyosua Jan 19 '16 at 10:44
  • Really someone decompling my application to get my client id and secrete had not occurred to me. I have sent an email off to someone at Google to see if I can get their opinion. I will let you know what I hear. – Linda Lawton - DaImTo Jan 19 '16 at 10:53
  • Thanks! I appreciate that. Yeah, my younger self definitely decompiled applications, intercepted my own PC's web requests, and inspected packets quite a bit, so I'm definitely overly precautious when it comes to my own application security. Though, I imagine I'll still screw something up. haha – Jyosua Jan 19 '16 at 21:15
  • 1
    My email has been forwarded to the "auth and security folks" at Google. In a hope that they can give me a tip on best practice. Lets see what they say. Nice when your email does the rounds at Google IMO means its a really good question. – Linda Lawton - DaImTo Jan 21 '16 at 07:44
  • Cool! Thank you for the update. I'm interested to see what they have to say about best practices. In the meantime, what I've done is set up a small relay script on an SSL-enabled server for generating the token. Basically, you give the script your authorization code and it requests the access token for you, printing the response from google to the page. You can then use any JSON library or custom methods to deserialize the response in your application code. Obviously, you'd also want to make sure to force SSL to be used when accessing the script URL. – Jyosua Jan 21 '16 at 08:38
  • Contact me if you are interested in doing a write up of your solution for this. I would be willing to host it for you. If you have your own hosting link it to me I would be happy to share it around for you. I think others will find your solution useful. – Linda Lawton - DaImTo Jan 21 '16 at 08:42
  • Once I'm done fully implementing a solution for this, I'll definitely get back to you. As I mentioned before, I setup a relay script, but to use it, you need to pass the authorization code via GET parameters. This isn't a big deal for short-lived authorization codes, but since GET parameters are saved in server-side logs, I don't want to use this method for refreshing an access token. Given that, I tried to change the script and my code to use POST parameters, but I've run into another issue: TLS 1.2 is not fully implemented in Mono and I'm writing a cross-platform application. – Jyosua Jan 26 '16 at 07:38
  • Because of that, I'm now trying to figure out a workaround so that I can send the refresh token via POST parameters without having to resort to using TLS 1.0. If it's not one thing, it's another, it seems. – Jyosua Jan 26 '16 at 07:49
  • I haven't heard from Google but I am following your progress. I have a number of windows applications as well. – Linda Lawton - DaImTo Jan 26 '16 at 08:01
  • Any updates on this please ... facing the same problem ... – Jim Oct 21 '16 at 18:43
  • 1
    @Jim Google intentionally doesn't support the workflow for desktop clients, so the way I got it working was to proxy my requests through a trusted server controlled by myself. I had to set up HTTPS to do this in a secure fashion using POST parameters, but I had to pay for a server that could support older versions of TLS for my applications that were using mono. In case it isn't clear, this server holds on to the client secret for me and transmits it along with the requests, so the user doesn't have access to it. – Jyosua Oct 21 '16 at 21:35
  • @Jyosua wow, thank you for your response. So the easiest way is just let the user make a client_id and client_secret themselves on Google Developer Console. – Jim Oct 21 '16 at 22:15
  • If that's an option for you, yes, that is definitely easier. In my case, my users were going to be ignorant as to how the implementation works for authorization, so I needed to use just one for the whole application across all users. – Jyosua Oct 21 '16 at 22:24
  • It's an option, but definitely a bad workflow to get authenticated. – Jim Oct 21 '16 at 22:30
  • The way I did it works and is fairly secure, but to be quite frank, I think both flows are pretty bad, haha. Going through so much really shouldn't be necessary. – Jyosua Oct 21 '16 at 23:20

0 Answers0