Client secrets in desktop open-source apps
JakubVanek opened this issue · 14 comments
Hi!
I would like to ask whether it is possible to include the client ID and secret in an open source application with the "Desktop" type of credentials. According to RFC8252, neither client ID nor secret can be considered confidential in these cases.
It is not possible to fully prevent client secret exposure if the OAuth2 flow is performed locally. Setting a breakpoint to the place where the authorization code is exchanged for refresh/access tokens is enough to compromise both the client secret and the client ID.
This is acknowledged on the OAuth 2.0 for Mobile & Desktop Apps page:
Installed apps are distributed to individual devices, and it is assumed that these apps cannot keep secrets. They can access Google APIs while the user is present at the app or when the app is running in the background.
[IANAL] However, section 4b of Google APIs Terms of Service prohibits inclusion of Client ID in open-source apps:
- Developer credentials (such as passwords, keys, and client IDs) are intended to be used by you and identify your API Client. You will keep your credentials confidential and make reasonable efforts to prevent and discourage other API Clients from using your credentials. Developer credentials may not be embedded in open source projects.
It could be argued that client secret encryption & code obfuscation are reasonable efforts to prevent the problem, but this is not applicable to open-source applications.
However, given that client ID and secret are essentially public, do they still count as developer credentials?
In the case of server-side web applications, the condition fully makes sense - server operators must ensure that credentials are only accessible to the running web app. In the case of non-mobile desktop apps this cannot be ensured.
Could we in that case distribute it with our application?
Thank you for any help you can offer me.
Jakub Vaněk
How bad is it when the client ID/secret can be extracted by just using the strings command? I have found one such application where this is possible (problem reported).
Greetings, we're closing this. Looks like the issue got resolved. Please let us know if the issue needs to be reopened.
Hello, it's not exactly resolved. The application in question currently requires each end user to create their own GoogleAPI developer application. This makes the application setup a lot more involved than it would otherwise be.
Ok, re-opening. Thanks for letting us know!
I also have this question
@sai-sunder-s do you happen to have any documentation you could direct people towards, for best practices regarding desktop authentication of OAuth applications?
I have the same question. I have a console app that opens browser and waits for auth response. But seems not right to package with client_id/secret. I'm going to test if put a simple webapp up front google server works well.
As per the text here: Installed apps are distributed to individual devices, and it is assumed that these apps cannot keep secrets. and here : You must never commit client credentials into publicly available code repositories. my understanding is that secret should not be commited to github but it is ok to be part of a desktop application.
Thank you, this sounds reasonable. Embedding the client secret into the application during application release (be it using CI or manually) would appear to me to comply with these requirements.
As far as I understand it, desktop apps and mobile apps are the same in that you should not use clientId/clientSecret since the secret will be available to the user. In desktop apps it might be a little more difficult to find but it is still possible to extract it, no matter how you encrypt or obfuscate it.
@sai-sunder-s the text you quote says these apps cannot keep secrets which to me means that you should never include a secret in these applications. Not just keeping them out of public source control but also not delivering them with the application either.
Desktop apps and mobile apps are considered "public clients" and should not use client secrets at all - they should use the PKCE authorization code flow without a secret: https://oauth.net/2/pkce/
The confusion that led me to this github issue is that AFAIK most of the oauth providers that offer a PKCE flow for public non-confidential clients do not require a client_secret, but for some reason google seems to want it
@sai-sunder-s the text you quote says these apps cannot keep secrets which to me means that you should never include a secret in these applications. Not just keeping them out of public source control but also not delivering them with the application either.
this is why I'm confused as well. i don't think the issue is resolved until a maintainer tells us the correct way to use google oauth for desktop apps - or confirms that google oauth is not suitable for desktop apps, which is what it's looking like.
OK, reopening - the technical concerns are indeed not yet resolved. Since opening the issue, I've forgotten why exactly have I opened it (I've moved on and am no longer involved in the original project). I do remember reading about PKCE and having some problems with it, though.
The reason I closed the issue is that it appeared to me that the "legalese" point of view is resolved: you must not make the client ID/secret available under an open-source license, but you can use it in open-source code.