@Oleg, I’ve been working through building a custom app to learn this a bit better and ran into a question. I specifically was a bit confused with all the authentication/validation endpoints required, so I decided to work through an example using an authenticated google API. I think having an example of how to do this in addition to the simple example would go a long ways for demonstrating best practices in a more comprehensive example. My questions:
Question 1: Is this how the initial screen in oauth2 authentication should look?
Since this is a nodejs app, I am using google’s nodejs oauth library to authenticate using oauth2. I was actually surprised that I was able to get to the point where I got my custom app authorized to pull data associated with my google account without too much issue. I did have one question come from that. In the app authentication config, I wasn’t sure what to put there. In the example, you are asking from some information from the user to mock up some kind of authenticated API access. In this case, I don’t think there is anything to ask from the user until authentication is completed. So, should I be doing anything else to make this step of the app configuration look better? In other words, this configuration of the app, results in the following step.
authentication: [
{
description: 'Authorize with Google',
name: 'Google Oauth',
id: 'oauth2',
},
],
The above screenshot is what you see after putting in the custom app’s URL. When clicking “Connect”, then you get the popup window that contains the list of google accounts to click on.
Question 2: How should I handle new access tokens automatically obtained by the google oauth2 client?
My main question I had is about what happens after the initial authentication. So, let’s assume we are doing a refresh days after the first authentication. The user maybe manually triggers a sync, so the /validate endpoint of the custom app has information posted to it about the authentication details of this particular account. This includes the last known access_token and the refresh_token, which is originally provided in the initial authentication.
I can use these to set the access_token and refresh_token and the library will automatically get new access_tokens on its own. However, I don’t see how I would be able to synchronously refresh the token myself and return it from the /validate endpoint, since the library is handling it all internally. The library has a way to listen for the token changes, but I’m not sure where I could post those changed values to. This is how I am setting the tokens on the oauth2client in /validate.
// setting this in the /validate endpoint
oauth2Client.setCredentials({
refresh_token: req.body.fields.refresh_token,
access_token: req.body.fields.access_token
});
Given the way that google’s oauth2 nodejs client library works, I don’t see how I can be sure to return an updated access_token from the /validate endpoint. This means that even though new access_tokens will be granted to the app, the access_token provided by fibery to the /validate endpoint will always be the same one that was originally granted when the app was first authorized for that particular account.
