Open hgeist2 opened 1 year ago
I'd like to help here; you say you don't have a frontend and if that is the case(I assume you are running your javascript on node) then this is the wrong place/library/authentication mechanisms.. The information here and in the migration workflows is meant for browser based authentication and not server to server communication. You probably want to start here: https://github.com/googleapis/google-api-nodejs-client
@dvanderb : Ok, thank you for your fast response.
I tried out service account and api key auth from the auth section: https://github.com/googleapis/google-api-nodejs-client#authentication-and-authorization . Unfortunately, blocked with "no token or no access rights" (something like this) when trying to list props from webmasters api. Next step was oauth, which leads to the outdated example i mentioned. I now see there is a new doc for oauth 2 updated workflow. Thank you for pointing me in that direction.
Problem of my use case is that this legacy node.js app runs on Google Cloud functions in one google acc, while webmasters api it tries to access is in another Google account. Do you think it is at all possible to make this cross account auth work with the new, tightended securiy / auth?
I totally hear you. Auth is not an easy place to be for anyone -- changes are coming faster than the ecosystem: docs, samples, libraries, and apps can keep up.
Yes, you should be able to make this work.
My guess is you'll want to look at supporting both a service account for the legacy app and individual user auth for the webasters api. You can use both approaches simultaneously, but the service account and user credentials (access tokens) cannot be mixed or interchanged.
I dont' have enough experience with the node.js client library to speak to it's documentation or support for per user auth, but I'll share info on using OAuth, which the JS and node.js client libraries wrap and interact with on your behalf. It may well be that an example is missing from the client libraries... and hopefully the OAuth docs fill in a missing puzzle peice.
Here's an overview of the steps involved in per user auth for web servers -- regardless of the client library being used. This is discussed in much more detail in Using OAuth 2.0 for Web Server Applications.
Now to speak to your frustration about churn, changes and having to rewrite your app... the OAuth interfaces described in the included links are about as stable as you'll find, the browser based JS libraries (like this one) are constantly evolving as browser vendors (Chrome, Safari, Mozilla, and friends) make privacy and security changes. Some features and functionality rely on older APIs and browser functionality that is being removed to improve user privacy and security. These changes are great for users, but really can cause a lot of churn and pain in code... especially older, legacy code bases.
A good way to minimize your risk of needing to update is to stick with pure server based auth flows and using browser JS (such as this library) only when necessary.
I came here with the same frustration. A super useful contribution to help people thru this would be to re-work https://github.com/google/google-api-javascript-client/blob/master/samples/authSample.html to work in the new approved way. Thx!
I must say i am very frustrated at this point. Google sends emails to my customers saying: "Your app uses an old auth worklfow, modernize until this and that date".
Then, you have documentation documents referencing 10 other docs that lead to examples like the following: https://github.com/google/google-api-javascript-client/blob/master/samples/authSample.html
Which yields "You have created a new client application that uses libraries for user authentication or authorization that will soon be deprecated."
Whats going on with Google? If your service was any smaller i would just drop it. So now your customers have to "figure out" which auth method works in this quarter or what? I am not going to dig through your trillion cross-linked api documents with outdated examples and apis and products that change their name with the season, for my paying google cloud customers, that will not pay me to learn whatever new kink you implemented in your auth apis again this year.
Please give a detailed answer on how i can implement an auth workflow for a backend app that runs in your cloud, the Google Cloud, and that does not have a frontend, using the webmasters API. Thank you.