What is the best approach for storing OAuth2 tokens?

Excellent summary… Highlighted!

2 Likes

I’m pleased to say that I have it all working as expected. Don’t forget I’m using the Xero API and not Google. This is the structure of my authorise server action file:

You’ll see some inactive Action Steps - they are there for my testing so is nice to just leave there commented out should I need to go back to it.

This is run whenever any API calls fail - I’ve put in an ‘Unauthorized’ Dynamic Event for the Server Connect AC component:

browser1.goto('/dmxConnect/api/Xero/authorise.php')

This can probably be fine-tuned further but it’s working and I’m happy :slight_smile:

Thanks again @Akayy and @psweb for all your help.

2 Likes

Well done @sitestreet, referring to @psweb’s query, does Xero API sends refresh_token only once, and only the access_token on future authorizations?

I’m still not completely sure on this.

It seems that when the Access Token is renewed, a new Refresh Token is also sent. However, it also seems that an old Refresh Token still works and gets the new Access Token. I will try and do some more research on that.

1 Like

Great news @sitestreet, well done.

Quite interesting how different OAuth APIs all work so differently, if Google OAuth could have kept handing the refresh token it would have made life far simpler, seems kind of silly that they don’t in my opinion, but I just assume it’s a security thing or something. Maybe they took lessons of Apple and are just being difficult though, which is also a possibility.

You mentioned about using the unauthorised event, which I also attempted to use, and it does work, it redirects as soon as it’s no longer authorised, I only wish there were another even like almost_unauthorised, so it could run my refresh access token script a few seconds before fully unauthorised, which would then give the user a more seamless experience instead of the browser suddenly redirecting them to an authorise script.
I got around the limitation by using the Action Scheduler however it does have some limitations, which is why i have to check every 5 minutes incase the timer resets from a user interaction.

Anyway, happy it is working and hopefully you can post a little Xero API guide when you have it all worked out.

1 Like

Yep, it’s all working nicely although I have hit an issue which I’m currently looking into but it’s Xero specific, I think, and not OAuth2 generally. Once I’ve sorted that (it cropped up once the client tested it) I will try to write an easy to follow how-to but I need to be sure I’ve understood everything correctly as I’d hate to post something and it not be right, even if it does work.

I completely agree about the unauthorized event not being graceful. Bouncing to a script and then returning isn’t ideal. I’m wondering if it could open a new tab or something and then close it but that’s for another day - if it’s even possible.

One possible solution is to run the authorise script on the main app screen and set the redirect to that same screen. Then, every time the main screen is visited, the check is made and refreshed if needed. That might make it less visible.

2 Likes

Can’t we use the catch on server-side for the unauthorised event triggering? Haven’t tried it myself, will let you know if I had any luck

Is it okay to store tokens locally on device for mobile development?
https://cordova.apache.org/docs/en/latest/cordova/storage/storage.html

Hello @sitestreet, this thread has been extremely useful for understanding the set up of the API for Xero - thank you.

In researching how to develop this for my application I have read another thread which comments that it is not possible to configure Oauth2 token handling as ‘Self maintain’ within the structure of the new Global Server Actions because a database query can’t be run before the Global Oauth Provider (Oauth2 with Salesforce) and the Oauth Provider can’t be set up inside an action. I haven’t found a way to solve this and searching the Wappler forum hasn’t shown up any solutions either.

Is this a problem you have encountered or has it not come up for you because your Xero API was developed before the Global Server Actions were released? If you have had this problem can you say how you got around it?

Hi @Marek. I haven’t come up against this probably because I did the Xero integration before the global actions were introduced. I will keep this in mind the next time I’m doing something like this, though, but I’m afraid it’s not particularly helpful to you right now. Sorry :frowning:

That said, I have made edits to the site which used Xero since globals were introduced and I did replace the actions for globals (database connection, security and mail) and didn’t have any issues.

1 Like

Hi @sitestreet,
Any chance of a xero integration walkthrough/guide when you get a moment? :+1: