Fortnox OAuth2 (New authorization workflow)

[richardrandak]

Originates from #159

[Sharparam]

I'm wondering how Fortnox believes this will play out with the (surely) large amount of integrations that rely on the non-interactive legacy flow for authentication.

Requiring user interaction for the new flow is going to outright break several integrations. In an email they sent when I inquired about it they said they do not plan to add the Client Credentials OAuth2 flow (designed for authentications that do not have a user and/or interactive session). Hopefully they go back on that decision.

[alalloo]

I completely agree. I had a chat session with Fortnox support today on exactly this topic, and it won't work for our use which is a non-interactive flow in an Azure cloud function. We are lucky to have an existing set of client credentials that will work for another 10 years, but they clearly did not consider our scenario and use. In that time they will hopefully have reconsidered.

This means we can stay on the old way for many years to come, but I notice the API is already marked as obsolete. We can suppress this warning in code (we run warnings-as-errors), but I hope it won't be removed from the client code until it really reaches end of life? @richardrandak

[richardrandak]

It won't be removed.

[richardrandak]

Well...

1. Already activated tokens will continue to work, so the change won't break existing connections. (at least i was told several times)
2. The new authorization flow requires one time human interactive session. After that you can maintain the token by refreshing it (with no human integration) every 30 days.

So the main problem is just to have a server listening for the callback... one horrible way to handle that is to set the callback URI to non existing URI (e.g. https://localhost:44312/) and the user can copy the authorization code from the URI himself :D ..and still would not be much different from the previous activation workflow when user had to copy client id and bring back the API key.

It makes things a bit complicated, but on the other side, finally the Fortnox API uses standard workflow.

[Sharparam]

Already activated tokens will continue to work, so the change won't break existing connections.

Yeah that's what I gathered as well, but new integrations (probably) won't be able to use it.

After that you can maintain the token by refreshing it (with no human integration) every 30 days.

Which works fine, until it breaks for some reason, and now you have to contact the client and ask them to auth again.

The bottom line is that the Authorization Code flow is not designed for this use. Fortnox is trying to force us to use it in a way it was not designed. OAuth2 has a mode for non-interactive session to maintain authentication. This is a solved problem. They refuse to implement it for some reason and it's very confusing.

Edit: What I imagine will happen if the legacy flow is completely disabled (at least for new integrations), is what a coworker half-jokingly suggested:

People will start saving the actual username and password, and then use that to automate the authentication process.

[richardrandak]

I agree.. would be nicer to support the dedicated flow. However, the problem you are describing is common for other API providers as well. In most cases I was dealing with, they've always supported only the Authorization Code flow.

Maybe the actual reason is that if they enabled the Client Credentials flow, it would be overused even for web app integrations just because it is simple to implement :D

[Sharparam]

This makes me sad. I guess I shouldn't expect much from enterprise APIs. The non-enterprise APIs I've used usually do either an API-key style auth, or use OAuth2 with Client Credentials flow.

[bpaolo71]

I was thinking about the refresh token that expires every 30 days.
Do I have to remember this expiration date by my self or I get a specific exception / message that says that it's time to refresh it ?
TokenInfo.ExpiresIn has always the expiration of the "normal" token

[richardrandak]

I never tried using expired refresh token. I assume it will give you a generic error like "invalid_grant".

[bpaolo71]

Thank you Richard. I'm a little confused and can't try it myself yet because we're not ready with the web part.
When i call await authWorkflow.RefreshTokenAsync(refreshToken, clientId, clientSecret); do I just get a new access token or both a new access token and a refresh token?
According to their example, the refresh token shouldn't change as it is valid for one month ! Or I misunderstand all ?

[richardrandak]

You get both access token and refresh token. The old one should be discarded. I am not sure how it is in Fortnox, but it is often like that for security reasons, that the previous refresh token becomes invalid.

So, the 30 days expiration period is basically valid only for an unused refresh token. :)

[bpaolo71]

ok, thank you !

[strndi]

I can still get access tokens the old way, so is it not discontinued yet?

request.get({
    uri: 'https://api.fortnox.se/3/',
    headers: {
        'Authorization-Code': '---',
        'Client-Secret': '---',
        'Content-Type': 'application/json'
    },
    json: true
}

Still works here, even on apps created just a few months ago. I didn't try an entirely new one though.

[richardrandak]

You are right, it works for me too.. I don't know what to say :)
I kept the old activation workflow in the SDK for now, but I guess it can stop working anytime.

[Sharparam]

As I understood it, the old method will stay available to old apps, but any new ones will not be able to use it. I also have not tried with a brand new app though.