Quickstart
Go from nothing to a working login by talking to the auth.is MCP server. You will connect the MCP to your AI tool, sign up, create a team (which creates your issuer), register your first client, and complete a first OIDC login against your own issuer.
The whole setup happens conversationally — you describe what you want and the tools do it. There is no separate console to log into first: connecting the MCP is the sign-up.
1. Connect the MCP
The auth.is management surface is an MCP server at https://mcp.auth.is. Add it as a connector in the AI tool you already use.
Claude (claude.ai) — open Settings → Connectors → Add custom connector, and enter the URL:
https://mcp.auth.is
Claude Code — add it from the terminal:
claude mcp add --transport http auth-is https://mcp.auth.is
Either way, the first tool call triggers an OAuth sign-in. Your tool discovers that mcp.auth.is requires authentication, registers itself automatically, and opens a browser window to login.auth.is. This page is where you create your auth.is account (or sign in if you already have one) and approve the management scope. One browser approval and you are connected — your AI tool holds a token and never sees your credentials.
The MCP registers your tool as an OAuth client dynamically and requests the mgmt scope against https://mcp.auth.is. You approve it once on the consent screen; after that the tools just work.
2. Confirm the connection
Ask your tool to run whoami (or just say "am I connected to auth.is?"). It returns your user and the teams you belong to. On a brand-new account the team list is empty — that is expected.
For a guided, ordered checklist tailored to your account, ask it to call get_started. With no team yet, it returns a single next step: create one.
3. Create your team and issuer
Tell your tool to create a team. Behind the scenes this calls create_team, which atomically provisions the team and its first issuer — a live OIDC provider at {slug}.auth.is.
A realistic request:
Create an auth.is team called "Acme" with the issuer slug "acme".
create_team takes:
| Field | Notes |
|---|---|
name | The team's display name, e.g. Acme. |
slug | The permanent DNS label of your login host — lowercase letters, digits, and hyphens, 3–63 chars, and free. It becomes https://{slug}.auth.is. |
issuerDisplayName | Optional; defaults to the team name. |
The slug is permanent — it is the DNS label of your issuer host and cannot be changed later. Choose it carefully. A taken or reserved slug comes back as a conflict, so pick another.
The moment this returns, https://acme.auth.is/.well-known/openid-configuration serves live OIDC discovery — the response includes that URL so you can verify it immediately.
4. Register your first client
A client is the application that will send users to your issuer to log in. Tell your tool what you are building and it calls create_client. The most important choice is confidential vs. public:
- Confidential — a server that can keep a secret (
token_endpoint_auth_methodisclient_secret_basicorclient_secret_post). A secret is generated and returned exactly once. - Public / PKCE — a SPA or native app that cannot keep a secret (
token_endpoint_auth_methodisnone). No secret; PKCE is the proof.
A realistic request for a server-rendered web app:
Register a confidential client called "Acme Web" with grant types
authorization_code and refresh_token, and redirect URI
https://app.acme.com/api/auth/callback/authis.
That maps to create_client arguments like:
{
"name": "Acme Web",
"client_id": "acme-web",
"token_endpoint_auth_method": "client_secret_basic",
"grant_types": ["authorization_code", "refresh_token"],
"redirect_uris": ["https://app.acme.com/api/auth/callback/authis"]
}
For a confidential client the client_secret is shown once, in this response, and never again. Have your tool hand it to you and store it in your secret manager immediately. If you lose it, rotate it with rotate_client_secret (which also invalidates the old one).
In production, redirect_uris must be https. http://localhost is accepted only in local development.
For a SPA, ask for a public client instead — token_endpoint_auth_method: "none", grant types ["authorization_code", "refresh_token"], and your app's redirect URI. PKCE is required for every client, so your library must send code_challenge; there is no secret to store.
5. Complete a first login
You now have everything an OIDC integration needs:
- Issuer / discovery:
https://acme.auth.is/.well-known/openid-configuration - Client ID:
acme-web - Client secret: (confidential clients only — the value from step 4)
- Redirect URI: the one you registered
Point your OIDC library at the issuer and start a login. To do it with nothing but curl — and to see exactly what each endpoint returns — follow the no-framework guide. It walks the discovery → authorize → code exchange → userinfo loop end to end.
By default your issuer authenticates users with username + password (they can create accounts if you enable self-signup — see Clients). Want "Continue with Google"? Ask your tool to add_identity_provider. Want the login page in your brand colors? Ask it to preview_theme, then apply_theme.