What is the difference between MCP OAuth and a service account?
OAuth delegates access from an interactive resource owner to an MCP client after a browser-based authorization flow. A service account is a non-human identity provisioned for one agent or automation and authenticated with a credential stored by that runtime. OAuth answers which person approved this client; a service account answers which automation performed this work.
When should an MCP client use OAuth?
Use OAuth when a person is present to sign in, review the requested access, and have tool calls attributed to their own account. The MCP authorization specification uses protected-resource metadata to help clients discover the authorization server, then an OAuth 2.1 flow issues tokens intended for that MCP resource.
- A person is adding a remote MCP server to their own client.
- The product must preserve the person's existing organization membership and permissions.
- Each employee should be distinguishable without sharing credentials.
- The client supports the server's registration and browser authorization flow.
When should an agent use a service account?
Use a service account when no person is available to complete an interactive flow for each run, or when the automation must remain operational independently of an employee account. Create one identity per agent or profile so access, authorship, rotation, and revocation remain independent.
- Scheduled research, reporting, synchronization, or monitoring.
- A shared company agent running outside one employee's session.
- CI, background jobs, and server-side agent orchestration.
- MCP hosts that cannot complete the server's supported OAuth client-registration flow.
Why is copying a human token into an agent unsafe?
A copied human token makes unattended work appear to come from that person, inherits permissions intended for their interactive account, and may remain embedded in configuration after their role changes. It also prevents an operator from revoking the agent without disrupting the employee.
What does a standards-based MCP OAuth flow require?
A protected MCP server advertises protected-resource metadata and the location of an OAuth authorization server. The authorization server publishes discovery metadata and supports an accepted client-registration approach. Public clients use authorization code with PKCE, tokens are sent in the Authorization header, and the resource server validates issuer, audience, expiry, and scopes on every request.
1. Client calls the protected MCP endpoint
2. Server returns 401 with resource_metadata
3. Client reads protected-resource and authorization-server metadata
4. Client identifies or registers itself
5. Person signs in and approves access
6. Client exchanges the authorization code using PKCE
7. MCP server validates the bearer token and scopesHow should a company support both identity types?
Keep human and agent principals in the same authorization model but label their type explicitly. Apply organization, workspace, and operation scopes to both; derive authorship from the authenticated principal; expose recent use and revocation controls; and never allow a request body to choose its own author.
Which authentication path does Handover support?
Handover supports named, scoped service identities for generic MCP hosts today. Gatana and other clients explicitly configured with Handover's Google OAuth application can use per-user Google attribution. Handover is adapting the first-party OAuth authorization-server pattern proven in Clara MCP so arbitrary compatible hosts can open a browser, register securely, and preserve the signed-in human identity.
Primary references