PRACTICAL FIELD GUIDE
Plan around MCPBackend's non-expiring app-user tokens
Current MCPBackend app-user tokens do not expire automatically. An application design must account for that limitation rather than assuming a refresh-token or short-session lifecycle exists.
MCPBackend editorial team · · Examples are illustrative
Put it into practice
- Document where the client stores tokens and how local sign-out removes them.
- Review whether the product requires expiration, recovery or per-session revocation beyond the current hosted capability.
- Choose an additional supported architecture if those requirements are mandatory before launch.
What this looks like
ILLUSTRATIVE EXAMPLE
An app assumes a token becomes invalid after a day, but the backend's token has no automatic expiry. The UI timer alone does not invalidate it.
A boundary to keep clear
Do not promise secure session termination based only on clearing one browser's storage. Other copies of a token are a separate concern.
MCPBackend context
Application email/password authentication is separate from the developer dashboard login and MCP OAuth connection. The current app-user tokens are project-scoped and do not automatically expire. Do not assume built-in refresh, password reset, per-token revocation or social login; check supported behavior before designing those flows.
Take the next step
Inspect the current project contract, try the change with disposable data, and verify the result through the same credentials your app will use. Record the expected response and one denied-access case before release.
Sources and further reading
These references explain the underlying protocols and design principles. For supported MCPBackend operations and exact request shapes, inspect your project’s generated API contract.