I am doing a proof-of-concept for a client using the weblocation connectors along with the importwebapi transformations. All is working fantastically except for the tokenisation.
The weblocation connector states “Note that implementation of OAuth2 by some web services may require frequent renewals of refresh tokens.” I am okay with that, as OAuth2 is built on some solid security functionality. The EasyMorph implementation of this works well.
Where I am coming unstuck is that in order to re-tokenise the connector, you have to go into the connector and Forget the authorization, then Authorize it each time. And the only way you know that it is time to retokenise is by getting a 401 (Unauthorized) status code during the execution of the transformation. I cannot then put this in any automated Launcher configuration, and I have to expose my end user to the innards of connector configuration.
Ideally there would be a “Web Location Reauthorize” step that I would just put at the start of a Transformation, or even better one which does the Test connection and triggers the Reauth only if a 401 comes back. Or the ultimate - a change to the importwebapi transformation to add a tick box “Reauthorize on 401 (Unauthorized) Error?” in the Options tab.
If anyone has had some similar learnings in this area, it would be great to hear them.
I see that this topic was raised over a year ago in the context of PowerBI (see here), but that mentioned v5 and we are already at that version…
Starting from v5, the “Web location” connector automatically refreshes Oauth2 authentication tokens stored in the connector. Note that this only works when EasyMorph workflows use the same connector that is hosted by EasyMorph Server and served to Desktops from the Server, not from a local file repository.
The mechanism works exactly as you described: if a request returns 401 (Unauthorized) EasyMorph automatically obtains a new token and stores it in the connector.
To make a Desktop use Server-hosted repositories, you need to link Desktops to Server as described here: Server Link explained
If using a Server-hosted repository doesn’t work, let me know the name/URL of the web API you’re trying to connect to.
UPDATE
Automatic OAuth2 token refresh works with a file repository too as long as the repository is shared between two or more Desktops via a shared folder.
Our proof of concept here is for a single user instance of a data update (moving data from a web-based bank management facility into an on-premises accounting system). See here
Sadly, the use case will not justify the on-going maintenance and setup cost of an EasyMorph server instance. We are trying to save maybe 1-2 hours of a single person’s time once a month, and remove a manual (error-prone) step.
With such a rapid move to the cloud of so many smaller apps now (most / many of which have APIs), it may be worth revisiting porting the re-auth functionality to the local repo.
As @dgudkov said in post update, local repositories also support automatic token refresh since v5. The only exception are embedded connectors - connectors that are hardwired into the project file. So, if you are using v5 EasyMorph with ‘shared’ connectors, token refresh should happen seamlessly automatically.
The other question is whether authorization provider (e.g. service you are connecting to - Salesforce, Gmail etc) issues new refresh tokens automatically upon expiration.
By default and by oauth specification there is no agreed flow for automatic refresh token re-issue, as opposed to access token re-issue which has its dedicated flow. In some sense, obtaining refresh token is deliberately designed to involve human interaction and includes user navigating to external service website (e.g. Salseforce or Gmail website), agreeing to external app (EasyMorph in our case) having access to user data, manual login/password entry etc and as such this interaction cannot be just wrapped into some action to be put into transform flow (well, I suppose technically this could be done - but it would involve browser window popping up mid-transform and this imposes serious limitations for unattended runs, for example there is no way to do this if project is being executed with EasyMorph Server).
Mostly, authorization providers deal with this issue by providing special scopes (like offline_access in Salesforce) that make refresh tokens non-expirable. In rare cases, authorization providers issue a refresh token alongside with expired access tokens, and EasyMorph can handle these scenarios too.
But if service you’re trying to connect to does not provide means to create non-expirable refresh tokens and does not issue new refresh tokens automatically, there is not much that can be done from the EasyMorph side to automate such case.
Particularly for Xero, automatic refresh should work if you use the offline_access scope Scopes | Xero Developer
