I'm planning to write a Kodi (former XBMC) plugin for Spotify using Python. Some time ago, Spotify deprecated their old library libspotify and introduced a new ReST based WebAPI. I would like to use this api to request data like the playlists, followed albums and other user specific stuff from Spotify. This WebAPI uses the OAUTH mechanism to authorize an application to use user-specific data.
Thus, I require a Client ID and a Client Secret. While the Client ID is public I have not problem in storing it in the sourcecode. But what about the Client Secret? This secret is required by the application to authenticate itself at spotify. Thus, it needs to be deployed as well.
How do I securly deploy this secret, such that a user of the plugin is not able to read out the secret?
I can't use obfuscation techniques because python is interpreted and a user can simply start an interpreter, import my modules and read out the reconstructed secret. The same holds for encrypting the key. The application needs to be able to decrypt the secret and because of this, I would need to deploy the encryption key as well. This is a chicken or egg problem.
Any suggestions about this? How does other software solve this problem?
EDIT: I just found this RFC6819. Seems like this is a general problem in oauth.
In this case, you can use the Implicit Grant Flow, which is designed for client-side applications where storing the secret is impractical for security reasons.
Related
I'm trying to make an app and I can't figure out how to sign in to a user with the python library firebase_admin. I don't have any code as of this moment. Let me know if you can help me out.
The Firebase Admin SDK is designed to be used in a trusted environment, such as your development machine, a server you control, or Cloud Functions/Cloud Run. It gets its authorization from its context or from a credentials file that you provide to it, and which gives it full, administrative access to the project. Therefor it doesn't need, and doesn't have a way, to sign in as a specific user.
If your use-case requires that you sign a user in to Firebase from your Python code, you can consider calling the REST API to authenticate. But the use-case for this would typically be to then pass the ID token you receive back to a user (similar to the use-case in creating custom tokens).
I am writing a basic python script and I am trying to use the Github API. Because I am new to the development scene, I am unsure of what I can share with other developers. Do I generate a new personal access token (that I assume can be revoked) or do I give them Client ID and Client Secret?
Can someone explain how OAuth (Client ID and Client Secret) is different from a personal access keys?
Does this logic work across all APIs (not just on Github's)?
The Short, Simple Answer
You should probably give them none of those things. They are equivalent to handing over your username and password to someone.
The Longer Answer
It depends...
Personal Access Tokens
Your personal access token is a unique token that authorises and represents you during API calls, the same way that logging via the web interface authorises you to perform actions there. So when you call an API function with a personal access token, you are performing that API action as if you yourself had logged in and performed the same action. Therefore, if you were to give someone else your token, they would have the same access to the site as they would have if you gave them you username and password combination.
Personal access tokens have attached scopes. Scopes control exactly how much access to GitHub a particular token has. For example, one token my have access to all private repositories, but another token only to public ones.
Client IDs
A client ID represents your application, rather than you. So when you create an application, GitHub gives you an ID that you use to identify your application to GitHub.
Chiefly this allows someone logging into your application using OAuth to see on the GitHub web interface that it's your particular application requesting access to their account.
Client Secrets
A client secret is a random, unguessable string that is used to provide an extra layer of authentication between your application and GitHub. If you think of the client ID as the username of your application, you can think of the client secret as the password.
Should I Share Them?
Whether you wish to share any of these things depends largely on how much you trust the other developers. If you are all working on the same application, it's likely that you will all know the client ID and client secret. But if you want to develop an open-source application that people will install on their own machines, they should generate their own client ID and secrets for their own instances of the app.
It's unlikely that you should ever share a personal access token, but if you have a bot account used by the whole team, then sharing the tokens could also be okay.
I'm writing a opensource app in python following this example:
https://developers.google.com/gmail/api/quickstart/quickstart-python?hl=it
I generated correctly the client_secret.json and ran successfully that example.
Now.. considering I'm starting to write my code and according with google doc:
Warning: Keep your client secret private. If someone obtains your client secret, they could use it to consume your quota, incur charges against your Google APIs Console project, and request access to user data.
so, how can I (in the future) share my app's code and keep at same time the client_secret.json secret?
Ok, I got the answer here:
https://developers.google.com/accounts/docs/OAuth2InstalledApp
This flow is similar to the one shown in the Using OAuth 2.0 for Web
Server Applications, but with three differences:
When creating a client ID, you specify that your application is an
Installed application. This results in a different value for the
redirect_uri parameter.
The client ID and client secret obtained from
the Developers Console are embedded in the source code of your
application. In this context, the client secret is obviously not
treated as a secret.
The authorization code can be returned to your
application in the title bar of the browser or to an http ://localhost
port in the query string.
In other words, if you specify that your project is an "Installed Application" while creating it in the Google APIs Console, you can safely embed secret in your code
I'm a python beginner, and I want to make a basic google tasks client. It'll be a native app. The point I cant get is how to keep the 'client secret' actually secret, as it's to be included in the program code.
I've searched and found a post, quoting a google forums post, and basically suggesting to give the thing away.
I have spent hours trying to get the thing, but, I have no answer at the moment. So, I have two questions to ask:
What are the consequences of giving the client secret away?
If letting people see the secret is dangerous, is there a way to keep it secret, or, is there a way to do a classic login to support application specific passwords to log into the google account?
I assume you're talking about OAuth.
Yes, you embed the secret - but no, it's not really a secret; see another post here: OAuth - embedding client secret in your application?.
Google's docs actually say the same thing; from : https://developers.google.com/accounts/docs/OAuth2#installed
The client_id and client_secret obtained during registration are embedded in the source code of your application. In this context, the client_secret is obviously not treated as a secret.
And there's no point in trying to protect it - it has to make it's way over the wire to get to Google, and anyone with Fiddler, etc. could watch it in plain text.
As to impact: the idea behind the client secret, I believe, is to protect the client vendor (that's you). Theoretically, if I know your client key and secret, I could make a malicious website/client that lets users log in legitimately but then deletes all their tasks and it would look like you were responsible. That probably makes sense to defend against with web services, but for an installed client, the user presumably downloaded it from somewhere (app store, website, etc) that hopefully made sure it was legitimate.
In my case I'm using the Dropbox API. Currently I'm storing the key and secret in a JSON file, just so that I can gitignore it and keep it out of the Github repo, but obviously that's no better than having it in the code from a security standpoint. There have been lots of questions about protecting/obfuscating Python before (usually for commercial reasons) and the answer is always "Don't, Python's not meant for that."
Thus, I'm not looking for a way of protecting the code but just a solution that will let me distribute my app without disclosing my API details.
Plain text. Any obfuscation attempt is futile if the code gets distributed.
Don't know if this is feasible in your case. But you can access the API via a proxy that you host.
The requests from the Python APP go to the proxy and the proxy makes the requests to the Dropbox API and returns the response to the Python app. This way your api key will be at the proxy that you're hosting. The access to the proxy can be controlled by any means you prefer. (For example username and password )
There are two ways depending on your scenario:
If you are developing a web application for end users, just host it in a way that your API key does not come to disclosure. So keeping it gitignored in a separate file and only upload it to your server should be fine (as long there is no breach to your server). Any obfuscation will not add any practical benefit, it will just give a false feeling of security.
If you are developing a framework/library for developers or a client application for end users, ask them to generate an API key on their own.