Regarding Incident with invalidated tokens 1/6-2022

[#1]

Hi,

Regarding yesterday's incident, we are still working on restoring the old tokens so that they might be used again. Unfortunately this is a slow process as we have to run a separate script for every integration. The current estimate is that this will take another 3 hours and should be rolled back after lunch today.

Please follow the status here, more information will be announced there.

• We strongly recommend that all integrations have a method to regenerate a new token in case something would happen to your token, even though the tokens have no expiry time frame
• There are other possible incidents where a token might need to be refreshed, and it is part of troubleshooting for those issues to refresh the token once in a while.

This is something that we are informing about in the startup guidelines for developing an integration towards Visma.Net Financials.

Visma.net ERP API Integrations Startup Guide

View more

The ISV should provide the interface for the client/user to interact with the web browser, and each user should be authorized to generate a token by their own credentials.
If there are multiple companies, you should ask the user to select/specify which company is the integration made for.
This can be a one-time set-up at the beginning, then once you generate the token you can store it for that user and can be used on the companies which one the user has access to.

You can Get the companies available for the used token/Integration user via Context endpoint
for mapping, user/token = Financials Company
https://integration.visma.net/API/ resources/v1/context

Currently, Token Life Cycle does not have any specific interval, it's planned to facilitate as never expires. Each consecutively generated token automatically invalidates the recently created one.
(Request made from the Same CLIENT ID & the Same Visma.Net Financials user for all integrations/company) 

ISV / Integrator should ask their ERP Customer to have a different user for each integration/company. In this way, the integrator will use the same "client_Id" for all the integrations, but the ERP Customer will be using a different user for each company during the authorization. This is the recommended setup for our ISVs for obtaining a token while using the same ClientID for all the integrations. 

In this way, If something goes wrong with one of the integrations (e.g. token gets invalidated), ISV generates a new token, then the other integrations will not be affected thus ISV can continue to use their existing token/s."

We are sorry for any inconvenience this has caused you.

Thank you.

[adrianm]

>We strongly recommend that all integrations have a method to regenerate a new token in case something

>would happen to your token, even though the tokens have no expiry time frame

Can you be more specific what you mean here?

You only support the "Authorization Code" grant (valid for 10 minutes and no refresh) so a user from the customer must be involved in generating new tokens.

How are we supposed to implement "a method to regenerate a new token" which scales to multiple customers/integrations?