Allow specifying access_token to use

[stephenplusplus]

Copied from GoogleCloudPlatform/google-cloud-node#1346
	@salrashid123 May 28, 2016 15:16
There are situations where you can end up with just the access_token. (eg. non-refereshable token for an endusers via oauth webflow). There doesn't seem to be any way to place that raw token and initialize gcloud node. (gcloud-java recently added it in: googleapis/google-cloud-java#1029 here are some references for the older googleapis node client: https://github.com/google/google-api-nodejs-client#making-authenticated-requests and a citation about overriding the config googleapis/google-cloud-node#678 (comment)
	@mbleigh June 24, 2016 19:25
+1 to the issue. I've issued a pull request against google-auto-auth that would allow for: var gcloud = require('gcloud')({ credentials: {accessToken: 'ACCESS_TOKEN_HERE'} });
	@stephenplusplus June 24, 2016 19:45
Thank you for the PR over there, @mbleigh! What do you think about just not using google-auto-auth if a user provides a token?
	@stephenplusplus August 19, 2016 00:44
continuing from googleapis/google-cloud-node#1410 (comment) There are a couple edge cases: Calls made with gRPC APIs won't use the token (Datastore, Logging, Pub/Sub for now) There are other libraries we use-- gce-images & gcs-resumable-upload-- that would need to be updated to accept just an access token (and we would have to provide the access token the user give us to those libraries) @murgatroid99 is there a way to provide gRPC with just an access token?
	@murgatroid99 August 19, 2016 02:33
The simplest way to use a plain access token would be to add it to the call's metadata, the same way you would add it to headers for an HTTP request. If you don't want to deal with adding it to every call, you can also create a CallCredentials object, similarly to how you would create one for GoogleAuth credentials: var creds = grpc.credentials.createFromMetadataGenerator(function(args, callback) { var metadata = new Metadata(); metadata.add('authorization', 'Bearer: '+ access_token); return metadata; }); Then you can pass it to a call in the options field, or compose it with SSL credentials using grpc.credentials.combineChannelCredentials and then using the resulting object to create a channel.
	@stephenplusplus August 22, 2016 12:53
Awesome, thanks!
	@sedouard February 8, 2017 02:49
Hey there. We're planning on adding GCE support to our cloud management platform. Through we're planning on getting an auth token from our users with permission scopes into GCP. Today can we pass access_token directly to this client? Or should I manually be adding the authorization header to all requests?
	@jmuk March 7, 2017 20:53
@stephenplusplus -- is there anything to do more?
	@diiiego83 July 14, 2017 09:51
any update? i really need to set my access token but i can't find a solution.
	@kwent October 19, 2017 02:02
+1 for this feature

[atistler]

+1

[kwent]

@mbleigh @stephenplusplus A PR has been sitting here since June 24, 2016. How can we help to make this happen ? Looks like a lot of us need this.

[stephenplusplus]

This is unfortunately a big effort that probably requires either @callmehiphop or myself to implement, since we're familiar with the different transport layers that exist across our APIs. For example, in some places we use the REST API, and in others, gRPC directly or through an auto-generated layer called "GAPIC". Each will require a different solution, so it's not a trivial addition.

Lately, our time has been spent on supporting a wider set of APIs and their features, as well as bug fixes and performance enhancements. I can't say when we will be able to get to this, but let me ping @alexander-fenster to see if he wants to weigh in on how this should be handled and prioritized.

[kwent]

@stephenplusplus Thanks for the answer ! Please @alexander-fenster let's prioritize 🙏Thanks a lot !

[tswast]

I really like the work that @jonparrott with the google-auth Python library. I'd also love it if there was a clear way to use any kind of valid credential for our Node.js libraries.