SmartAuth 2.0.54: security audit and fixes

A full audit, followed by fixes

All of SmartAuth's code has been reviewed: Dolibarr pages, API, OAuth2 server, synchronisation engine and mappers. The cryptographic foundations (JWT tokens, PKCE, refresh token rotation) were sound. The weaknesses lay mainly in the administration pages inherited from the module generator, and in the gap between the rules applied by the REST API and those of the synchronisation engine. This release corrects them.

Everyone sees only what concerns them

The dashboard, the token list, the device list and the logs now require the SmartAuth read permission and are limited to the current entity. A user can no longer revoke, rename or delete anything but their own tokens; operations on other people's tokens are reserved for administrators. OAuth consents, devices found by their identifier and push notification logs also respect the entity.

Action links (revocation, deletion, renaming, settings on the administration page) check the CSRF token: a booby-trapped link opened by an administrator no longer has any effect. The token history and the device information displayed on the user record are escaped, which closes a stored XSS flaw.

Synchronisation follows the same rules as the API

The offline synchronisation engine now applies the mappers' visibility rules, like the REST API: a user who only sees their own projects or events does not retrieve others through synchronisation. Synchronisation conflicts no longer keep or return sensitive columns (password, API key). Documents listed or downloaded go through Dolibarr's access rules.

Sessions and passwords

A password reset now reliably revokes OAuth2 sessions, in addition to mobile tokens. For a member who also has a user account, the new password is written by the Dolibarr object, which keeps the two identities in step, and the old password kept in clear text ceases to be accepted.

Changing your password from the account page logs out the other sessions. Deleting a self-service account revokes mobile sessions and anonymises the contact and the third party. Deleting a device cancels its tokens. SSO logins are rate-limited by address and by identifier, and all password hashes handled by Dolibarr are recognised.

Single sign-on to the Dolibarr back office

The SSO login callback now reaches SmartAuth's handler, and the login page admits internal users, the only ones accepted by the back office. The consent page displays members correctly, and an application that requests a new authentication no longer causes a login loop.

Other fixes

• redirection targets that browsers turn into an external address are refused;
• a refresh token lost in a race responds invalid_grant instead of a server error;
• the application list displays again under MySQL;
• several fatal errors on certain extrafield types are fixed;
• push notifications target recipients according to their entity and group permissions, and the sending log can be purged;
• French accents are restored in the translations.