Separate OAuth consent, bearer-token storage, identity headers, and authenticated access decisions.
Where each credential belongs
The authentication boundary separates OAuth consent, bearer-token storage, non-secret identity headers, and the access decision itself. Mixing them is the most common cause of a leaked token.
- OAuth consent lives in the client; XMemo never sees a pasted token on that path.
- XMEMO_KEY lives in the environment or a supported secret store, never in a config file committed to git.
- Identity headers are plain labels and are safe to write into configuration.
- Public discovery is read-only and secret-free.
Token-based client configuration
Reference the environment variable from the client config so the real value never appears in the file.
{
"mcpServers": {
"XMemo": {
"type": "http",
"url": "https://xmemo.dev/mcp",
"headers": {
"Authorization": "Bearer ${env:XMEMO_KEY}"
}
}
}
}
What a rejected request looks like
A missing or insufficient credential is rejected before any memory is read. An empty result set is a valid no-match answer and is not an authorization signal.
401 — no valid bearer token or API key was supplied.
403 — the credential is valid but lacks memory:read or memory:write.
200 with zero results — authorized, nothing matched.