We ran into the same thing on our own control panel right after upgrading to 9770, and tracked it down. It isn't a revocation race. 9770 changed what impersonation requires from the session that calls it.
The API reference served by a 9770 server now says this about ImpersonateUser (POST /api/v1/settings/domain/impersonate-user):
"The caller must hold a refresh-capable session (one with a clientId)."
A refresh-capable session is one opened by calling auth/authenticate-user with a clientId. Our integration logged in without one, as yours probably does. That login still works, and so do all the normal sysadmin calls. But every impersonation is refused with 400 NO_PERMISSIONS, both impersonate-user and manage-domain (POST /api/v1/settings/sysadmin/manage-domain/{domain}). That's the step in your log.
We fixed it by sending a clientId at login, unique per client instance, for example myapp- plus 16 random hex characters, generated for each API client object or process:
POST /api/v1/auth/authenticate-user
{ "username": "admin", "password": "…", "clientId": "myapp-3f9c1a7e5b2d4c60" }
Don't use one fixed clientId for every process. SmarterMail keys its sessions by (user, clientId), so with a shared constant each new login replaces the previous session for that user.
All your other workers then start getting 401 Token not found.We learned that the hard way on an earlier build.
Log out when you're done (POST /api/v1/auth/logout-user with that session's token).
On our install, a session opened with a clientId gets a 15-minute access token but a refresh token valid for 60 days.
A client that logs in on every request without logging out would pile up sessions on the server. Logging out ends that session and every impersonation made from it, so do it after you've finished using the impersonation tokens, not right after obtaining them.
We tested that logging out one session doesn't affect the others, as long as each one has its own clientId.
Keep the impersonation token separate from the login token. The docs also say an impersonation session is tied to the session that created it. It ends when that admin logs out, loses impersonation rights, or is disabled, or 24 hours after it started.
If your client overwrites its main token with the impersonation token (ours did in one place), log out with the original login token, or you'll end only the impersonation and leave the admin session open.
For MSP Control
The login request has to change, so the fix needs to come from the MSP Control developers, they need to send a clientId when authenticating. I don't know of a server-side setting that turns the old behaviour back on.
Until they release an update, it may be worth pointing them to the ImpersonateUser entry in the 9770 API docs.