Refresh Token Handling

To cover a potential security issue, we are updating our authentication/authorization services to correctly handle refresh tokens.
This change, will likely cause issues with integrations that have cached refresh tokens.
Because this is an area that can be exploited we urge any integration operator/partner using our APIs to use standard practice and request a new refresh token, and implement fall back logic if they fail to obtain valid tokens.

Questions and answers

My refresh token is still not expired, but yet I fail to get a new access token. Is this a bug?

A refresh token might not have expired yet, but it could still be rejected by our Auth system for a variety of reasons:

• A refresh token can be used only once. After that, the newest refresh token must be used the next time.
• A refresh token is always linked to a session in our Auth system. The token will be rejected if the related session has been removed for whatever reason (session has been idle for too long, or it has been explicitly revoked, or lost due a technical error, etc)

Whenever you fail to obtain a new pair of tokens using your refresh tokens you should fallback to username and password again.

Does this mean users have to re-enter their credentials in third party apps?

It depends. Only do this if experiencing issues. We do not recommend using Easee credentials on any other system or app other than ones owned or recommended by Easee. If your integration does not work, you will need to re-authorize to gain new credentials.

Do I need to renew all tokens?

No. There is a chance that sessions will be revoked in this update. When that happens, your integration will likely see errors. You should implement retry-logic and catch these scenarios and after some failures, request new tokens.

What other alternatives do we have?

We are exploring industry standards e.g OAuth when it comes to authN/Z. We will update you when this is decided along with a date and timeline.