Authentication
How an MCP client signs in to the hosted server — discovery, registration, PKCE and consent.
Standard OAuth 2.1, discovered from the server itself. Your MCP client does all of this; you only sign in and approve.
1. Discovery
The first unauthenticated call gets a 401 whose WWW-Authenticate header
points at the server’s protected-resource metadata:
curl -s https://mcp.loginwith.dev/.well-known/oauth-protected-resource{
"resource": "https://mcp.loginwith.dev",
"authorization_servers": ["https://loginwith.loginwith.dev/"],
"bearer_methods_supported": ["header"]
}2. Registration
The authorization server is LoginWith’s console org,
https://loginwith.loginwith.dev/. Its discovery document publishes a
registration_endpoint, and the client registers itself there (RFC 7591):
POST https://loginwith.loginwith.dev/oauth/register| Rule | |
|---|---|
| Client type | Public only — token_endpoint_auth_method: "none" |
| Redirect URIs | https, or loopback |
| Rate | Registration is rate-limited |
3. Authorization code with PKCE
The client runs the authorization-code flow with PKCE (S256). You sign in to
the console as usual.
4. Consent
Because the client was not built by LoginWith, you are shown a consent screen for it before any code is issued. Approve it to connect; deny it and the client gets nothing.
What the server checks
The resulting access token is a console token, sent as
Authorization: Bearer ….
| Check | Where |
|---|---|
| Signature and issuer | The MCP server, on every request |
| Your permissions | The management API, on every tool call |
The agent can do what you can do in the console, and no more.