oAuth Access Token Response differs from the standard

[Qics_Development]

Visma,

I'm in the progress of connecting to the Visma.net API.

I ran into an issue where our application doesn't handle the Visma.net oAuth authorization correctly.

The reason for this is that the Visma.net implementation differs from the standard.

When I mean standard, I refer to the https://www.oauth.com/ website and the standard that's described there. I was wondering why Visma.net has chosen to divert from this standard and if it's possible to get the standard responses instead of the custom Visma.net response.

To elaborate:

Authorization Request - Identical to standard described on  https://www.oauth.com/

Authorization Response - Identical to standard described on  https://www.oauth.com/

Access Token Request - Identical to standard described on  https://www.oauth.com/

Access Token Response – Not identical!

https://www.oauth.com/oauth2-servers/access-tokens/access-token-response/ describes the response as follows:

HTTP/1.1 200 OK

Content-Type: application/json

Cache-Control: no-store

Pragma: no-cache

{

  "access_token":"MTQ0NjJkZmQ5OTM2NDE1ZTZjNGZmZjI3",

  "token_type":"bearer",

  "expires_in":3600,

  "refresh_token":"IwOGYzYTlmM2YxOTQ5MGE3YmNmMDFkNTVk",

  "scope":"create"

}

Visma.net response is:

HTTP/1.1 200 OK

Content-Type: application/json

Cache-Control: no-store

Pragma: no-cache

{

  "token":"1f729814-1a98-4c8e-860b-76ec004742f5",

  "token_type":"bearer",

  "scope":"financialstasks"

}

My question is: Is there a way for me the get the standard response format as described on https://www.oauth.com/

A thing I did notice is that Visma eAccounting API DOES return the responses formatted the same as described in the standard, so Visma.net seems to be the odd one out. Is this on purpose and how do I get around this without recoding our generic oAuth2 implementation with an exception for Visma.net?

Thanks in advance!

[Yıldırım]

Hello, 

---

@Qics_Development wrote:

Is there a way for me the get the standard response format as described on https://www.oauth.com/

How do I get around this without recoding our generic oAuth2 implementation with an exception for Visma.net?

---

This is correct. Visma.net ERP API Access Token Response returns the token value in  the "token" key instead of "access_token". According to information we've received from the infrastructure team this has been handled in this way when it's implemented due to internal dependencies so that it was kept in the "token" key.

Additionally, The token does not expire, meaning that it can be stored in the client-application. If requesting a new token for the same User with the same ClientId, the previous token will be invalidated. Please see Visma.net ERP API Integrations Startup Guide for further information.

At the moment  an exception should be added in the implementation for Visma.net API to read "Token" key. 

[Qics_Development]

I hate to say this, but that is a terrible way to implement oAuth.

Every application that has a generic oAuth implementation and wants to connect to Visma.net ERP will have to make an exception for this to work. Even in Postman (which has this same generic implementation) you have to manually copy and paste the "token" value to use it.

I can only strongly urge you, to motivate your development and infrastructure team, to follow the standards for oAuth implementation also with the Access Token Reponse, because breaking the standard to make it fit better in your own infrastructure is probably never the optimum results. Especially not if it's the part of the code that is used to connect the application to external applications.

Thanks for the answer though. Just disappointed that this is the outcome.

[Yıldırım · Accepted solution]

We definitely understand the frustration and the rightful argument. Since every integration has already been built based on this exception, replacing it now would be a breaking change.

On the other hand, If oAuth implementation refactoring would be put on the agenda in the future, we'll emphasize this to the team to reconsidering this approach and find out a plausible solution.

For now, by far the quickest and convenient solution would be building a small function to deserialize the "token" key from the response body.

[Florian Haase]

Would it work to deliver the token both in "token" and "access_token"? For me it sounds that this could solve the needs for both - Visma and standard-implementations?

[Qics_Development]

I think that this depends a lot on how strict the receiving system upholds the standards. A lack of refresh_token field could be breaking for one implementation and not so much for another one.

If the receiving system is very strict and only accepts a response that's formatted towards the standard, even adding an extra field would break it.

[adrianm]

According to the specification, refresh_token is optional. A client requiring it is non conforming.

Extra fields are indirectly allowed "typically along with some additional properties about the authorization."

So having both "token" and "access_token" is fine according to the standard but I assume Hyrum's law applies as well.