Change to our new Identity Server
We have implemented a new Identity Server that provide endpoints for authorization and authentication. This Identity Server will replace our existing ID/Auth Servers.
We will shut down the ID/Auth servers in the production environment (https://id.vismaonline.com and https://auth.vismaonline.com) by the 30th of September 2018. Until then, please make sure to update your solutions that goes towards these endpoints as soon as possible. We have updated our documentation when it comes to authorization and authentication towards the new Identity Server.
When it comes to the sandbox environment we will do the same changes, but the shutdown date is the 1st of February 2018. If you have not implemented this change in your solutions, your existing test applications will stop working.
The new Identity Server is used for:
- Authorize and Authenticate new customers.
- Recieve Access Tokens, Identity Tokens and Refresh Tokens.
The new Identity Server is located at another url, in both Sandbox Environment and Production Environment.
- Authorization Endpoint: https://identity-sandbox.test.vismaonline.com/connect/authorize.
- Token Endpoint: https://identity-sandbox.test.vismaonline.com/connect/token.
- Authorization Endpoint: https://identity.vismaonline.com/connect/authorize.
- Token Endpoint: https://identity.vismaonline.com/connect/token.
New Required Features
Authorization and Token Requests
Token requests towards the new Identity Server must always be in Content-Type: x-www-form-urlencoded.
We have changed the namings of the scopes, and two additional mandatory scopes are added. Below is a list of mandatory and selectable scopes:
When requesting tokens, the Refresh Tokens will be always be updated.It is really important to save both Access Token and Refresh Token, the same Refresh Token cannot be used more than once.
Force New Login
If you want the user to log in again (even if you're already logged in) to authenticate multiple times in different companies, for example. Then use prompt=login in the querystring when you ask for authentication code against auhorize endpoint.
Why do Visma change Identity Server?
- More secure and stronger algorithms of token signing with certificates instead of symmetric keys.
- The new Identity Server follows the OAuth 2.0 standard and the OpenID Connect protocol.
- Simplifies future integrations and single-sign-on against other Visma products.
- Ability to access more user and company information in new claims.
What do you need to do?
- Change url to authorize-endpoint: https://identity.vismaonline.com/connect/authorize in production and https://identity-sandbox.test.vismaonline.com/connect/authorize in sandbox environment.
- Change url to token-endpoint: https://identity.vismaonline.com/connect/token in production and https://identity-sandbox.test.vismaonline.com/connect/token in sandbox environment.
- Provide the two new mandatory scopes “offline_access” and “ea:api”
- Prefix existing scopes with "ea:"
- If you extract the access token yourself and use something in it, there are some minor changes in some claims: The value in "sub" is now UserId, not the e-mail address as before and the e-mail address is found in a new claim called " email ". Previous claim "VismaCustomerId" has renamed "customer_id" and all scopes are prefixed with "ea:" except "offline_access" which is a global scope.
When can I make the change?
The API already support tokens from the new Identity Server, so it's free to switch to the new one, the sooner the better.
Do I need to contact Visma before I change?
No, your clients are already registered in the new Identity Server with the same client id and client secret as you have in current.
What happens when I switched over to the new Identity Server?
All applications need to authenticate again and then everything is as before.
Due to Visma's security policy, it may be necessary to authenticate again against the Identity Server if the authenticated user change password or lock their Visma Online account.
What happens if I do nothing?
From the 30th of September 2018 in production environment, the applications will not be able to request new access tokens (HTTP status 400) and therefore not able to use the eAccounting API.
If you have any questions about this, don’t hesitate to contact us at [email protected]
Updated over 4 years ago