OAuth2 with Desktop Application Security

问题:

I have an Electron application that's basically a Google Drive client. I am planning to use OAuth 2.

However, Google API requires me to register my application where a client_secret is generated. Since this is a desktop application, I have my client_secret stored in a server. The authentication URL is generated in the server and sent to the user.

I'm worried that people can pretend to be the app and do things on behalf of my client_secret. If someone with malicious intent creates an unauthorized app and sends requests to my server, they could theoretically do malicious things on my application's behalf.

Is there anything I can do to mitigate this problem or is this not an issue?

edit: People will only access their own files. Just like they would on drive.google.com (read/write/delete files)

回答1:

Edit: Verifying that a request came from your desktop application and not a clone of it to your server is not really possible unless you control the locations where it is installed, but for a user program you don't. You can place some meagre barriers, but you can't provide any guarantees. It looks like iOS/Android are moving on this front, I imagine the only viable implementation would be for the OS to send a verified credential on your behalf, that is OS level support, not application level support.

As for general OAuth 2.0 authentication methods...

If we go through the motions here, we can analyse each method of authorisation and take a look at the risk of this. https://developers.google.com/identity/protocols/OAuth2

1. https://developers.google.com/identity/protocols/OAuth2WebServer (I think you're in this camp, but there's no client_secret here)
   • Only risk of DOS against your client credentials. The responses are only ever acknowledged and forwarded to the specified redirect Uri, so requests can be made on your behalf for tokens, but only your server will ever receive the tokens (assuming the user agent is decent), you should deal with the case where you receive unknown token responses.

2. https://developers.google.com/identity/protocols/OAuth2InstalledApp

   • Risk of User installing a malicious app. When you lose the client_id, client_secret and the redirectUri (you have no way to keep these private against debugging of the device), then anybody will be able to make apps on your behalf. This is an unfortunate problem for mobile apps. The only defence is the User consent screen for now, that is, hopefully the User notices by looking at the consent screen that they have been duped into installing a malicious app from the store instead of your legitimate app.

     I'd love to see some more work on this front, perhaps the App Stores could hold some credentials on your behalf and then confirm that it is your app requesting, I imagine that would involve some hash checking etc.

     I'd be even happier to be corrected on this one, but I see nothing preventing the above problem :P

3. https://developers.google.com/identity/protocols/OAuth2UserAgent
   • Same as 1.
4. https://developers.google.com/identity/protocols/OAuth2ForDevices
   • Same as 2.

回答2:

Personally I would create a proxy service which mimics the Google Drive REST API, but implements your own AAA mechanisms. That way all of the secrets are secured on the server and you can add fine-grained access control.