Using OAuth2 tokens for interactive usage of GCP services instead of service account (keys)

Question

In order to limit the number of service accounts to manage as well as handling their keys, I'm exploring other ways of accessing GCP resources from a developer laptop or desktop so I can run ad-hoc scripts or interactive programs (e.g. Jupyter notebook) that access GCP services.

Using gcloud auth application-default login generates, after authenticating via a web browser, a refresh token that can be used to get and renew access tokens that can be used to interact with GCP services.

The workflow I'm following is this:

1. Run gcloud auth application-default login. This generates a JSON file on my disk that contains the refresh token.
2. Export the JSON file location as GOOGLE_APPLICATION_CREDENTIALS env variable GOOGLE_APPLICATION_CREDENTIALS=/Users/my.username/.config/gcloud/application_default_credentials.json 
3. Use that file to authenticate via Google auth library and interact with different GCP services.

This is convenient, as it reduces the need to circulate, secure and, if needed, share service account key files around team members. However, I have noticed that the refresh token provided does not expire and is still valid.

Unless I'm missing something here, this makes application_default_credentials.json file as sensitive as a service account key. If it gets lost or compromised it can be used to get access tokens without the need to re-authenticate, which is fairly insecure, IMO.

We're aware of the GCP security best practices recommend using service account (and their keys) for service-to-service workloads. This scenario I'm describing is for ad-hoc, development/testing of code from a developer's or engineer's laptop. We think that forcing users to interactively authenticate via the web to get new tokens every few hours would be more secure and convenient than using long-lived service account keys stored in the hard drive.

I have read through [1] but I could not find a definitive answer.

• Does anyone know if there is an expiration for these refresh tokens?
• Is there a way of controlling and limiting their lifetimes (ideally to hours or minutes)?
• What is the best/common practice for this scenario? Using a single service account (and key) per individual user?

[1] https://developers.google.com/identity/protocols/OAuth2#expiration

Answer 1

Note: User Credentials have Refresh Tokens too.

Does anyone know if there is an expiration for these refresh tokens?

Google OAuth Refresh Tokens do not expire. They can be revoked.

Is there a way of controlling and limiting their lifetimes (ideally to hours or minutes)?

You could periodically revoke the Refresh Token which will invalidate the Access and Client ID tokens. This means that you are handling the Refresh Tokens which adds another security issue to manage.

What is the best/common practice for this scenario? Using a single service account (and key) per individual user?

If you use User Credentials (the method where you log in to Google) you will receive SDK warnings and if you make a lot of API calls, you will become blocked. Google does not want you to use User credentials in place of Service Account credentials. The verification process for User Credentials requires more effort on Google's backend systems. User Credentials are assumed to be created in an insecure environment (web browsers) whereas Service Account credentials are assumed to be in a secure environment.

Best practices are to issue service account JSON key files to an individual application with only the required permissions for that application to operate. For example, if you create a tool that only needs to read Cloud Storage objects, create a service account with only read permissions. Periodically the service account keys should be rotated and new keys downloaded and old keys deleted. Each application should have its own service account JSON key file. I wrote an article on how to securely store JSON key files on Cloud Storage. This helps with rotating keys as your application just downloads the latest key when needed. (link). My article discusses Google Cloud Run, but the same principles apply.