MCP server OAuth flow on Sume: discovery, consent, PKCE, and scopes

Sume's hosted MCP server is its own OAuth authorization server. A request to https://mcp.sume.com/mcp without a token gets a 401 that points to protected-resource metadata; the user signs in and picks permissions on a first-party consent page on mcp.sume.com; and the client trades the authorization code plus a PKCE verifier for a bearer token scoped mcp:read, or mcp:read and mcp:write.

The steps come from MCP OAuth and API keys and the MCP quickstart, read on 2026-09-26. Parameters, error codes, and token lifetimes come from the metadata production served that day and the server code behind it, so they describe current behavior. Sume's basics page says the CLI and hosted MCP still work but are not part of the primary integration path today; backends call the Format API or the Developer API over HTTP. Per-client setup commands are in Connect Claude Code, Cursor, or Codex to Sume.

What are the steps of Sume's MCP OAuth flow?

In order:

• The client calls https://mcp.sume.com/mcp without a token and gets 401 with a WWW-Authenticate header that names the protected-resource metadata URL and scope mcp:read.
• The metadata lists authorization_servers as the MCP origin, not www.sume.com or app.sume.com.
• The client sends the user to https://mcp.sume.com/oauth/authorize, which redirects to the first-party consent page GET /oauth/consent on the same host. A user who is already signed in still sees consent.
• Consent shows Permissions: Read locked on, the Write toggle off by default. Continue posts the choice to POST /oauth/consent/decision, and the browser returns to the client with a code.
• The client exchanges the code and its PKCE verifier for an access token.
• The client calls https://mcp.sume.com/mcp with that bearer token.

Where is the discovery metadata, and what does it say?

Two public documents describe the server. The resource audience is https://mcp.sume.com/mcp. www.sume.com remains a deprecated authorization-server surface that the metadata no longer advertises, and interactive clients should never be sent to app.sume.com for MCP OAuth.

https://mcp.sume.com/.well-known/oauth-protected-resource/mcp
https://mcp.sume.com/.well-known/oauth-authorization-server

What does the client send to authorize and to the token endpoint?

The authorize redirect carries response_type=code, client_id, redirect_uri, code_challenge, code_challenge_method=S256, state, and resource; scope is optional. Only S256 is accepted. A redirect URI must use https, http on localhost or 127.0.0.1, or Cursor's own cursor:// callback.

The token request sends grant_type=authorization_code, code, client_id, redirect_uri, and code_verifier; resource defaults to https://mcp.sume.com/mcp. A code that does not match its client, redirect URI, and resource, or a verifier that does not hash to the challenge, gets invalid_grant. Any other grant_type gets unsupported_grant_type.

Dynamic client registration posts redirect_uris (up to 10) to /oauth/register. token_endpoint_auth_method must be none: these are public clients with no client secret.

Which scopes can a Sume MCP token carry?

Two: mcp:read, which is required, and mcp:write, which always includes read; what each session can call is in Connect Claude Code, Cursor, or Codex to Sume. Any other value in the authorize request's scope, mcp:paid included, fails with invalid_scope.

The user decides, not the client: the granted scopes come from the Write toggle on the consent page, even when the client asked for mcp:write. A token issued without write gets insufficient_scope on write and paid tools; fixes are in Sume MCP troubleshooting.

How long do codes and tokens last?

In the current server, both are short, and there is no refresh:

• An authorization code lasts 10 minutes and works once. A second exchange of the same code gets invalid_grant.
• An access token lasts one hour. The token response carries access_token, token_type Bearer, expires_in 3600, and scope, and no refresh token.
• The server issues no refresh tokens: a client may list refresh_token in its registration grant_types, and the server ignores it.
• An expired or revoked token gets the same 401 challenge as a missing one, so the client runs the authorization flow again.
• /oauth/revoke revokes a token, with no client authentication.

How do I confirm the session and keep the token safe?

Call mcp_health. Under OAuth, authenticated.auth_source is mcp_oauth, and the credential block currently shows type oauth_access_token, the client_id, and the granted scopes.

An MCP OAuth token is not a Sume API key, and the rules for storing and sharing it are in Safe automation for AI agents. Two points belong to the flow itself: sume login does not broker hosted MCP tokens, and automation that does not speak OAuth sends an API key instead, as Authorization: Bearer $SUME_API_KEY or x-api-key but not both.