Creating Service Account auth with fromJSON()

[calculuschild]

Describe the solution you'd like
If possible, I would like to create a Service Account auth from an environment variable instead of requiring reading from an external JSON file. However, it appears this functionality is not present in this current library, where oAuth2 clients can be created from environment variables, the Service Account can only be created via an external .json file.
Describe alternatives you've considered
In the other library (https://github.com/googleapis/google-auth-library-nodejs) this is possible via the fromJSON() function. It is not clear if this library is is a newer version of that one, or the vice-versa, but it's not clear why it is available there but not here.
Additional context
The other library states:

Instead of loading credentials from a key file, you can also provide them using an environment variable and the GoogleAuth.fromJSON() method. This is particularly convenient for systems that deploy directly from source control (Heroku, App Engine, etc)

Specifically pointing out the convenience for systems like Heroku, which I use.

If this is already possible, how exactly do I go about that here?

[JustinBeckwith]

Greetings! This npm module, googleapis takes a direct dependency on google-auth-library, and really just exposes it. If you stringify the JSON that makes up your key, and stuff it in an env var, something like this ought to work out:

const {google} = require('googleapis');
const keys = JSON.parse(process.env['keys']);
const auth = google.auth.fromJSON(keys);
google.options({auth});

Now onto why this isn't the default :) Generally - storing secrets in env vars is considered less secure than alternatives like using a secret manager, or an encrypted file. This is a good read on the subject:
https://diogomonica.com/2017/03/27/why-you-shouldnt-use-env-variables-for-secret-data/

That having been said, you should be able to JSON.stringify the key, and slug it in a heroku env var :) Let me know if you run into any problems!

Oh I almost forgot - last time I had to do this, I also base 64 encoded the stringified JSON to avoid weirdness with quotes and env vars. May be worth considering the same!