Say Goodbye to Refresh Tokens! Introducing Client Credentials for Service Accounts

We are rolling out a new option to use Client Credentials as a direct alternative to the Authorization Code Flow with refresh tokens for integrations that utilize service accounts.
What This Means for You
With Client Credentials, you can now request a new access token at any time using just three pieces of information:
ClientId
Client secret
TenantId
The best part? You no longer have to handle refresh tokens at all for customers using a service account. This dramatically simplifies token management and improves access reliability.
Seamless Migration Process
We understand that changing your authentication flow can be a hassle, so we've made the migration path as smooth as possible.You can migrate from the existing refresh token flow to Client Credentials without any customer interaction! We will automatically create and store a customer consent that matches the scopes you currently have for the existing token. A customer's consent is valid indefinitely until they actively choose to revoke it.
Don't Have TenantId Yet?
If your current implementation doesn't store the tenantId for your customers, here are a few ways you can easily get hold of it:
Decode the JWT: Decode the existing access token (no need to verify the signature, as the public key is not available). The tenantId is available as its own claim within the token payload.
Use Webhooks: Add webhooks for the Consent created and Consent revoked events in the developer portal. The events are triggered upon a customer's activation or deactivation, and will contain the TenantId.
Use Existing Scopes: If you currently have the scopes "companyinformation" or "settings" on active tokens, you can retrieve the field "DatabaseNumber" from the /3/companyinformation or /3/settings/company endpoints. This value is identical to the TenantId.
Need maximum flexibility?
You can still use the Client Credentials flow and the traditional Authorization Code Flow in combination for the same integration (clientId) and customer (tenantId). This is perfect if you need separate tokens for both service accounts and user accounts!
Check here for details on the request and response https://www.fortnox.se/developer/authorization/get-access-token-using-client-credentials


