I've built a web application which uses spotify api and it uses client id and client secret which is present in main.py i.e on the backend side of my application to fetch data regarding songs. Now I want to deploy the app on heroku and want to know whether it will be safe to deploy it like this or should I move client id and secret somewhere else.
Don't include the client id and the cilent secret into the code. Just add there a comment and the user can just add his own secrets.
You can do few things here:
Store your client_secret within an environment variable source
Use some kind of secure storage to save it as Azure KeyVault an then retrieve it directly from your code
Related
I am trying to use the 'compute_v1' client library to START/STOP VMs in GCP. I need to do this across 'PROJECTS' so I am planning to use the IAM , RBAC approach for Service Accounts created with the “Service Account Token Creator Role” assigned.
How do I go about setting up the Credentials in my client.?
right now I just use my 'login' related json key file as follows:
os.environ["GOOGLE_APPLICATION_CREDENTIALS"] = "path/xxxxxx.json"
The scope of this application is to STOP/START a list of VMs based on a project and do this on demand.
All is well , now I want to use this in production across multiple projects.!
Any direction of how to Authenticate and impersonate the RBAC for each Service Account is much appreciated.
I have developed a Google Cloud Function (GCF) in python, which i want to access from a web service deployed on AWS (written in python). While in the development phase of the GCF, It had Cloud Function Invoker permission set to allUsers. I assume that is why it didn't ask for an Authorization Token when called.
I want to revoke this public access and make it so that i can only call this function from the web service code and it is not accessible public-ally.
Possible Approach :In my research i have found out that this can be done using the following steps:
Removing all the unnecessary members who have permissions to the GCF.
Creating a new service account which has restricted access to only use GCF.
Download the service account key (json) and use it in the AWS web application
Set environment variable GOOGLE_APPLICATION_CREDENTIALS equal to the path of that service account key (json) file.
Questions
How to generate the Access token using the service account, which may then be appended as Authorization Bearer within the HTTP call made to the GCF? Without this token the GCF should throw error.
The docs say not to put the service account key in the source code. Then what is the best way to go about it. They suggest to use KMS which seems like an overkill.
Do not embed secrets related to authentication in source code, such as API keys, OAuth tokens, and service account credentials. You can use an environment variable pointing to credentials outside of the application's source code, such as Cloud Key Management Service.
What are the bare minimum permissions i will require for the service account?
Please feel free to correct me if you think my understanding is wrong and there is a better and preferable way to do it.
UPDATE: The web service on AWS will call the GCF in a server-to-server fashion. There is no need to propagate the client-end (end-user) credentials.
In your description, you don't mention who/what will call your GCF. A user? A Compute? Another GCF? However, this page can help you to find code example
Yes, secret in plain text and pushed on GIT is not yet a secret! Here again, I don't know what performing the call. If it's a compute, functions, cloud run, or any service of GCP, don't use JSON file key, but the component identity. I would say, create a service account and set it to this component. Tell me more on where are you deploying if you want more help!
Related to 2: if you have a service account, what the minimal role: cloudfunctions.Invoker. It's the minimal role to invoke function
gcloud beta functions add-iam-policy-binding RECEIVING_FUNCTION \
--member='serviceAccount:CALLING_FUNCTION_IDENTITY' \
--role='roles/cloudfunctions.invoker'
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.
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