3

As an exercise, I'm developing a desktop application with which users need to log in to a web service. A logical use-case for OAuth2 one would say, but I'm beginning to doubt its usefulness. I am looking for two-legged authentication, which leaves the client credentials, implicit and resource owner password flows available.

Because I would like users to be able to directly log in inside the application (not through a browser and redirect URI), the implicit flow falls away as an option. The other two flows require for the client_id and client_secret to be sent along, and I've read plenty of times it is unsafe to store the client_secret inside your desktop application.

My question is this: how unsafe is this really? How easy is it for adversaries to decompile (desktop) applications and figure out the client_secret? I could consider accepting the risk, so that I can use OAuth2's client credentials flow, because rolling my own authentication scheme would probably be even less secure.

P.S. Someone mentioned using implicit flow and temporarily starting a webserver at localhost as the redirect URI to circumvent a browser, but that seems excessive if not insecure. Any thoughts?

Improve this question
1

Look into the process of OAuth for client-side applications.

Your OAuth flow should look something like this:

  1. User logs in
  2. Your API returns an access token for that user
  3. Your desktop application stores the user token
  4. Future requests send the token, and the API uses it to authenticate the user

You cannot realistically protect a global secret key in your application, nor do you really have to.

Improve this answer
4
  • 1
    You have to if you don't want to use a redirect URI through your browser. If you're not sending along a client secret, you'll have to submit a redirect URI, which either goes through your browser (which I don't want), or a temporary webserver at localhost (which seems hardly a good solution with firewalls and all). I'm just wondering how risky it actually is to store the secret, and if OAuth2 is really the best solution for a desktop application situation.
    – Stijn Frishert
    Feb 2 '15 at 15:27
  • Depending on the API you're using, you can probably use a non-http url (for example, myapp://oauth-response), and capture that in your application
    – Joel L
    Feb 2 '15 at 15:29
  • I know iOS/Android support that, but do desktop apps/exes?
    – Stijn Frishert
    Feb 2 '15 at 15:29
  • On the desktop, your application can also register to handle specific url schemes. As an alternative, you can use an in-app browser, so you don't have to open (for example) Google Chrome for the user to log in.
    – Joel L
    Feb 2 '15 at 15:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.