Why do cloud vault non-expiration authentication tokens fail after long time?

Hi Victor,

Tokens with the REST API are not identical to tokens in other systems, where the token is a pre-generated static token that is designed for use by one integration. Whilst M-Files tokens with no explicit expiry are typically re-usable, you should in particular note the comment on the Developer Portal (developer.m-files.com/.../

Note that you should not expect tokens without an expiry to last forever; many situations may cause the token to become unusable.

In the case of a cloud instance it is possible that the server was upgraded or had some other maintenance applied to it that caused the token to expire. It is good practice to design any integration around the premise that the token may expire (and a 403 returned) and need to be re-requested. If you cannot do that for some reason then you may want to look at providing authentication details inside the HTTP request itself (X-Username, etc.) which avoids the need for a token.

Regards,

Craig.

Hello Craig,

Thank you for your clarification. I'll take care of the re-authenticating.

The authentication token is returned when logging on with credentials (and some other information). In my mind, certain authentication actions have already taken place and makes using a token 'more efficient' than specifying username and password (X-Username, etc.) in the header of each request.

But the page also states:

The M-Files Web Service will return an authentication token regardless of whether authentication was successful or not.

Is the login procedure no more than a valid user/vaultId check and returning the authentication details object as an encrypted (JWT?) token, and the credentials are not even verified?
The M-Files server would decrypt the token and authenticate/authorize each request using the decoded authentication details?

Still, I'd rather not specify user credentials in plain text in the headers of each request...

You are pretty much correct. The authentication token doesn't actually even authenticate the details, which is why you get a token regardless of whether the credentials are correct. It's only upon the actual request for data from the vault is the authentication tried and you get a 403 if it is incorrect. There are a number of reasons as to why the original token - even without an expiry - may become unusable, from the credentials becoming invalid to the cryptographic libraries being updated and the previous token becoming unusable. These possibilities are perhaps even more likely in the cloud due to the transient nature of the cloud hosts.

I understand your concern about credentials in the HTTP headers, and it would certainly be a last resort for me as well, but if you are executing requests over a HTTPS connection then the details are at least encrypted in transit.

My recommendation is as per my original message: handle the 403 and re-authenticate. If the token fails after re-authentication then it is possible that something else is problematic (vault offline? credentials incorrect?) and you'll need some exception handling and remediation process.

Regards,

Craig.