How do my customers sign in to my MCP server?
A protected MCP server has to know who is calling it, because each caller gets their own credentials and their own permissions. MCPCloud gives you four ways to establish that identity: they sign in with the OAuth provider your server already calls, your own product vouches for them through federation, they prove an email address with a one-time code on your branded page, or they create an MCPCloud account. If you run an OAuth provider, the first is almost always the right answer — it is one consent screen on your own site and nothing for your customer to create. If you have no identity provider at all, switch on the emailed code.
Why a name is needed at all
A public MCP server needs no identity: anyone may call it and every caller gets the same answer. The moment a server acts on someone’s behalf — reading their tickets, posting as them, spending their quota — it needs to know whose data it is touching, and it needs somewhere to keep the credential that reaches it.
That is what an end user is on MCPCloud: an identified, revocable caller of one server, scoped to the tools you allow, with their own upstream credential. An end user is not a member of your organization and is never a billable seat. The only question is where their name comes from.
The four answers
They differ in one thing: who the person has to prove themselves to. Everything downstream — per-caller credentials, the tool allowlist, traces, revocation — is identical in all four.
- Sign-in on your page. Your customer types their email on your branded page and receives a six-digit code sent under your name — or presses Continue with Google or GitHub, if you offer them. No password, no sign-up form, no verification step. Switches under End users → How customers sign in.
- An MCPCloud account. Your customer signs up with MCPCloud itself — a password and a verification email — and then connects on your branded page. It is what happens when nothing else is switched on, and it is the only mode where your customer meets our product rather than yours.
- Your OAuth provider (upstream sign-in). Your customer presses “Continue with <your product>” and approves on your own consent screen. The credential they already give you becomes their identity here.
- Your own sign-in (federation). Your backend signs a short-lived assertion and hands the person over. For a product with its own login but no OAuth provider.
Upstream sign-in, if you have an OAuth provider
This is the one that removes a step rather than moving it. Your server already calls your API with a token your customer authorized; upstream sign-in says that the same authorization can establish who they are. One consent screen, on your site, and no MCPCloud account anywhere in the path — including for someone whose first contact is adding your endpoint to an MCP client, before any browser is involved.
You configure two things beyond the OAuth settings you already have: an endpoint that returns the signed-in user, and the path to their stable id inside that response. After the token exchange MCPCloud calls that endpoint server-to-server with the token it just obtained and reads the id. Nothing the browser touched is ever trusted for this, which is the same rule “Sign in with GitHub” lives by.
The id must never change for a person. MCPCloud keys their account on it, so a provider that recycles ids would hand one customer another’s data. An email and a display name can come along too, but only so you can recognize someone in your end-user list — neither is ever used to authenticate anyone, and neither can reach an existing MCPCloud account.
Federation, if you have a login but no OAuth provider
Federation reaches the same place from the other direction: instead of MCPCloud asking your provider who someone is, your backend asserts it. You register an issuer and a public key, sign a short-lived RS256 assertion for your signed-in user, and post it to MCPCloud, which verifies it and signs them in.
It works for any product with a session, which is its advantage. The cost is that you operate a signer: a key pair to hold and rotate, a JWKS route to serve, an endpoint to mint assertions, and a bearer token that is replayable for its lifetime. Upstream sign-in has none of those, which is why it is the better answer when both are possible.
An emailed code, if you have no identity provider
Without a provider or a login of your own, somebody has to establish that an email address belongs to the person typing it. The emailed code does exactly that and nothing more: your customer enters their address on a page carrying your name, logo and color, receives a six-digit code from “<your product> via MCPCloud”, and is signed in. The first time creates their account; every time after, the same two steps sign them back in. They are never asked for a password and never see a workspace.
A code lasts ten minutes, allows five tries, works once, and is only ever issued for a server whose publisher switched this on. One address can be sent five codes an hour per server, so a connect page cannot be used to flood someone’s inbox. Your plan includes a number of codes per server every 30 days, and the End users tab shows how many are used. If they run out, customers are pointed to whichever other method you offer, which is a good reason to keep one on. A code never signs in a member of an MCPCloud organization — those accounts hold production infrastructure, so they are sent to the normal sign-in instead.
On the same page you can also offer “Continue with Google” and “Continue with GitHub”. These run through MCPCloud’s own Google and GitHub apps, so there is nothing for you to register — and, for the same reason, the provider’s consent screen names MCPCloud rather than you. Your sign-in page tells your customer so before they click. If you want your own name on that screen, register your own app with the provider and use upstream sign-in instead.
It is offered only when the server has no identity of its own. Switch on upstream sign-in or federation later and the code stands by rather than appearing next to it: one server, one way in, so the same person is never two accounts.
Choosing
Work down this list and stop at the first that applies. Nothing is exclusive at the platform level, but only one can be what a customer meets on your connect page, so pick deliberately.
- You run the OAuth provider your server calls → upstream sign-in.
- You have your own login but no OAuth provider → federation.
- Neither → the emailed code. One switch, and your customers never leave your page.
- Still evaluating → leave it alone; an MCPCloud account is the default and needs no setup.
What none of them change
Whichever you pick, an end user is still deny-by-default against your tool allowlist, still resolvable in traces, and still revocable from your end-user list — and revoking still locks them out immediately, including if they re-authorize with your provider afterwards. They are still never a billable seat.
Switching modes later does not migrate anyone. A person who signed in through your provider or through federation is a different principal from the same person signing in another way, deliberately: collapsing them would let a weakness in one mode reach into the other. The one exception is the pair that share an identity — an emailed code and an MCPCloud account are both keyed to the verified email address, so moving between those two keeps everyone connected. Otherwise, plan on the people already connected staying where they are.
Common questions
Do my customers need an MCPCloud account?
Only if you choose the default. With upstream sign-in or federation they never see MCPCloud’s signup at all — they sign in with your product and land on your branded connect page, already connected.
Are end users billed, or counted as seats?
No. An end user is a caller of one server, not a member of your organization, and is never a billable seat in any of the four modes. End-user access itself requires Pro or above on your side.
What happens if I revoke someone?
Their access stops immediately and stays stopped. In upstream sign-in in particular, re-authorizing with your provider does not restore it: the revoked check runs before any credential is stored or any session is minted.
Can a customer’s sign-in ever take over an existing MCPCloud account?
No. Both upstream sign-in and federation mint a synthetic principal in a reserved, non-routable namespace, derived from your organization and the provider’s id for that person. An email asserted by a provider is recorded for display and is never an authorization key, so it cannot resolve to an account someone else created.
What if the same person uses two of my servers?
With upstream sign-in they are one identity across every server in your organization, because the principal is keyed by organization and provider rather than by server. Two different organizations configuring the same provider get two isolated identities, which is what stops either from minting the other’s users.