Itgenoda494 An obsoleted refresh token can not be used on Exact Online. This occurs when an Exact Online user is associated twice with the same OAuth app

Wiki (en)
, ,
1

During the execution of a Data Hub job on a database with at least one Exact Online data container the following error may occur:

Error itgenoda494:
An obsoleted refresh token can not be used on Exact Online.
This occurs when an Exact Online user is associated twice with the same OAuth app.
The remote server returned an error: (400) Bad Request.
Please generate a new refresh token and make sure to keep the refresh token chain intact.
https://start.exactonline.nl/api/oauth2/token
System.Net.WebException
ValidationException
at System.Net.HttpWebRequest.GetResponse()
at Invantive.Data.Providers.Http.HttpBasedProvider.DoRequest(GlobalState owner, ExecutionOptions executionOptions, HttpWebRequest request, String url, ObjectDefinition objectDefinition, QueryObject queryObject, String partitionCode, String callSafeNameOverrule, String anonymizedPostText, Boolean allowRetryOnNoConnectionMade, Boolean allowRetryOnConnectionLoss, ParameterList parameters, Guid nativeCallUid, Boolean throwExceptionOnNonSuccessfulStatusCode, Object requestBody, ExecutionStatistics& executionStatistics, ODataErrorProcessingInstructions& oDataErrorProcessingInstructions)

Bad Request for Old Refresh Tokens

The error indicates that the short-lived password (“access token”) has expired and the (possibly more) long-lived password (“refresh token”) was used together with the fixed client secret in an effort to acquire a new access token from the authorization server with an authorization request. However, the refresh token used also already had expired, becoming a so-called “old refresh token”. This triggers the 400 Bad Request message, which Invantive SQL translates into an itgenoda494 error code.

Please note that Exact Online has a different interpretation of long-lived for refresh tokens: the refresh token is being replaced with each new access token by a new refresh token, effectively building a chain of refresh tokens which can not be interrupted.

There is a unique chain of refresh tokens with each combination of OAuth client ID (an “application”) and user.

Old Refresh Tokens and Data Hub

Invantive Data Hub can use multiple techniques for establishing a connection to Exact Online. Historically, the preferred way was to use the then really long-lived refresh token in combination with the client ID and client secret. This followed the so-called Code Grant Flow of the OAuth2 specification.

With Exact Online changing to refresh tokens that continuously change and where only one value is valid, this became unfeasible. Besides an ever changing value - which is currently memorized in the Invantive Keychain - there is also a problem with concurrency. When the same combination of user and application (client ID) is being used across multiple devices in a cluster or independent processes on a single server, only one instance will succeed in acquiring a new access token and new refresh token. The communication to all other running instances and persistence of the refresh tokens requires either a single node for exchanging this security-confidential information or a complex setup.

Given the considerable and avoidable maintenance effort to work with Code Grant Flow on Data Hub installations, an alternative solution was provided described on Circumvent two-step verification and refresh tokens on Exact Online using Data Hub.

In a typical Data Hub environment, both the user credentials (user, password and TOTP-secret) as well as the client secret are registered. Initially, the connection is set up using the Implicit Grant Flow. When the client secret is present, the connection is extended to the full Code Grant Flow. In case the refresh token becomes old, the Implicit Grant Flow is used on the next log on to automatically recreate a valid refresh token.

Single Winner for Valid Refresh Token

The extension from Implicit Grant Flow to Code Grant Flow is only done when the client secret is present. This solves the issues with the single valid refresh token on Exact Online. However, in case another node or process is running on the same client ID and user, the two instances will compete for a valid refresh token.

This competition will have only one winner. All other instances will receive an itgenoda494 error. Currently, Invantive Data Hub does not automatically fall back to the Implicit Grant Flow when this error occurs.

Solution of itgeneor494

To avoid the itgeneor494 error, you will need to either make sure that no concurrent processes run using the same client ID and user, or to stick to the Implicit Grant Flow solely.

Further Reading

The changes on the Exact Online API platform are summarized on Impact Exact Online API adjustments July 1, 2021. Related articles on the Exact Online refresh tokens getting obsoleted are: