PRACTICAL FIELD GUIDE
Diagnose invalid credentials without exposing passwords
An invalid_credentials response identifies a failed login, not a reason to log the submitted password. Check the project and request mapping before changing the user's data.
MCPBackend editorial team · · Examples are illustrative
Put it into practice
- Verify the app uses the intended project auth endpoint.
- Inspect field names and transport errors with secret values redacted.
- Test a known disposable account and show a generic useful failure message in the UI.
What this looks like
ILLUSTRATIVE EXAMPLE
The login form accidentally targets the staging project while the account was created in production. The same email does not imply a shared user store.
A boundary to keep clear
Never include raw passwords or bearer tokens in analytics, support screenshots or browser console logs.
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.