ApplicationDefaultCredentialsError on AWS about identity-toolkit-python-client HOT 9 CLOSED

Yes, it should be False if it's not on Google App Engine/Cloud Engine. Thanks for pointing out this error. I will change the default value of use_app_default_credentials to False.

from identity-toolkit-python-client.

Ok, thanks. But I've managed to set it to true when using the downloadable json file and adjusting that env variable to point to the json file. My question then is, if there is any difference in security strength between using False or True+JSON? Because it then might be the case that people will just think "it's not needed anyway". At least a warning should then appear when using "use_app_default_credentials=False"

from identity-toolkit-python-client.

Additionally, now the docs are out of sync: https://github.com/google/identity-toolkit-python-client#initialize-gitkit-client-instance

from identity-toolkit-python-client.

The security enhance is that if the environment variable is set on host machines, there's no need to provide service account credentials in the code, which makes it less likely for some careless developers to expose their credentials in their code on a public repository like Github.

Additionally, Google App Engine/Cloud Engine already set this environment variable for each project, so there's no need for developers to provide any service account credentials if they are using GAE/GCE. The purpose of this change is to simplify the work of using Identity Toolkit on GAE/GCE, therefore, it shouldn't have affected existing users. I will fix the backward-compatibility problem and update the doc shortly.

from identity-toolkit-python-client.

Ok, but if use_app_default_credentials=False doesn't use any credentials at all, how could that be a sensible default? v0.1.8 made you use the p12 file which gets replaced by the json file if use_app_default_credentials=True. In that case, it would make more sense not to remove the server_api_key kwarg (for backwards compatibility, but with serious warnings), but just add the use_app_default_credentials kwarg and use that if it is provided.

What am I losing when setting use_app_default_credentials to False instead of True? Will then the aws-backend-to-google server-to-server communication be susceptible to a MITM attack or what?

from identity-toolkit-python-client.

If use_app_default_credentials is set to False, then your old code should work as always without any difference. It won't be less secure than before, and you still need to pass in the service account credentials through constructor as you already did in your old code.

If use_app_default_credentials is set to True, the library will read the credentials through environment variable instead of reading from constructor parameters. This means 1) You don't need to hardcode the credentials in code; 2) If you are using GAE/GCE, you don't even need to set the env variable yourself, because GAE/GCE already does that for you.

Note that server_api_key has nothing to do with service account credentials. It's just not required anymore by any API call. You are right though that we should preserve this param for backward compatibility in this minor version, and eliminate entirely in a major version.

from identity-toolkit-python-client.

This server_api_key is the same as the private_key in the JSON file, but stored as a PFX file, right?

If you say that server_api_key is no longer used, then this implies that the private_key in the JSON file is also irrelevant. The private_key may be relevant for the oauth2client initialization, but not for the communication to the authentication server, you say?

Because if this is not true, then I don't understand how the GitkitClient is able to work without any private key at all (server_api_key not required)

Then the only credentials needed are client_email and the client_id, and those are getting "protected" py putting them in the file pointed to via GOOGLE_APPLICATION_CREDENTIALS?

I just called gitkitclient.GitkitClient() without any parameters, but having the GOOGLE_APPLICATION_CREDENTIALS variable set, and it worked flawlessly. Is that the intention of the modification? To move client_email and client_id out of the code? Wouldn't it then be better to remove the use_app_default_credentials keyword altogether, check if client_email and the client_id are set, and if they are, perform a non-default-credentials initialization, and if not, then check if the GOOGLE_APPLICATION_CREDENTIALS exists and use that, otherwise raise an exception?

The private key is really not getting used by Gitkit? I thought it was required for signing messages sent to Googles authentication servers.

from identity-toolkit-python-client.

server_api_key is not the private key in the JSON file you download, it's just an API key with little security protection that the library used to use when making trivial API calls which don't require service account credentials, namely /publicKeys API, and the API key is no longer needed now to call /publicKeys, so I cleaned it up in the code. All the other API calls, such as deleteUsers or uploadUsers require service account email and private key.

The intention of this change is merely to make it easier for App Engine users by not requiring them to set service account email and private key manually. So in your case, you don't need to make any changes to your old code once we change the default value of the flag to False. But if you really want to use the new default credential feature, then what you have done now is correct, except that you need to set the use_app_default_credentials to True after we change the default value to False.

It's a good point that you proposed to remove the flag and check whether service account email and private key are set. However, I added this flag due to the fact that service account email and private key are not strictly required by GitkitClient, you can still have a working auth server if you don't need the feature to manually manage your users(e.g. delete users, upload users, get oob code...). That's also why in the previous code, it didn't check whether an empty value is passed in in __init__. If the flag was removed, then the intention of passing in an empty service account credential would be ambiguous, it could either mean that the developer doesn't want to use a service account or they want to use default credentials. Therefore, I added this flag to allow developers to choose what they really want.

from identity-toolkit-python-client.

Please upgrade identity-toolkit-python-client to 0.1.10. We believe that your issues should be resolved in this version.

from identity-toolkit-python-client.