Skip to main content
Experimental version.This is the latest in-development version of AI-Implement. Features may change without notice and behavior is not guaranteed. Switch to the latest stable version here.
The admin UI supports per-user sign-in through Google or Microsoft, so each operator authenticates as themselves instead of sharing one access code. You can configure either provider, both, or neither.

​
How access is decided

Two things must both be true for someone to reach the admin UI:
  • Their provider authenticates them
  • Their verified email matches the allowlist
The allowlist is stored in the orchestrator’s database and edited on the Access page at /admin#access. OAUTH_ALLOWED_EMAILS and OAUTH_ALLOWED_DOMAINS only seed that list. They apply until the first Save changes on the Access page, and from then on the stored list is the only authority. Both are comma-separated. Each entry is trimmed and lowercased, and empty entries are dropped. Every entry carries a role:
  • An address seeded from OAUTH_ALLOWED_EMAILS gets the admin role.
  • A domain seeded from OAUTH_ALLOWED_DOMAINS admits people only as user.
  • Only a listed address can be admin — a domain never confers it.
A save is refused if the result would lock out the person saving it, or if it would leave no admin address.
The allowlist is fail-closed. With nothing seeded and nothing stored, every sign-in is denied — including yours. Seed at least one address before you switch operators over.
Prefer listing individual addresses over a whole domain. A domain entry admits everyone who has an address there, and only ever as a user.
If nobody can sign in, an operator with host access runs node dist/access-recovery.js --email <address> to restore it.

​
Create a provider application

Pick the provider you want to sign in with. Configuring both is fine — operators then choose at the sign-in screen.
Configuring both breaks MCP sign-in for anyone who can only use Microsoft: an MCP client is never offered a choice, and always signs in with Google. Either provider works on its own.
Google has 2 provider specific environment variables, both retrievable in the Create the OAuth Client step:
  • GOOGLE_OAUTH_CLIENT_ID
  • GOOGLE_OAUTH_CLIENT_SECRET
1

Create a Google Cloud project

In the Google Cloud console, open the project picker in the top bar and choose New Project. Name it something recognizable, such as ai-implement-sso.If your company has Google Workspace, set the parent organization so the project is governed by it. No billing is required for what follows.
2

Configure the consent screen

Open Google Auth Platform. Depending on the project, it opens either a Get started wizard or the Overview page.Work through the Get started wizard’s screens:
  1. App information — an app name and a user support email.
  2. Audience — choose Internal or External, below.
  3. Contact information — an email for Google’s notices.
  4. Finish — accept the user-data policy and click Create.
On the Overview page, the left menu is where each part of the setup lives:
  • Branding — the app name and support email.
  • Audience — the user type, below.
  • Clients — the OAuth client, created in a later step.
  • Data Access — the scopes, declared in a later step.
  • Overview — has the Create OAuth client button, used in a later step.
  • Verification Center and Settings — not part of this setup.
Set the Audience to match how your operators sign in — the choice follows their email domain, not the orchestrator’s URL. Operators at example.com reached through an orchestrator at ai-implement.example-dev.com choose on example.com.Internal fits when every operator signs in with an account in your Google Workspace organization. Google admits only accounts in that organization, so a domain check runs ahead of the orchestrator’s allowlist, and no Publish app step or test users are needed.Internal has one condition: the Cloud project must belong to that organization. Create the project while signed in with a Workspace account and choose the organization as its Location, or the console leaves Internal disabled.
With Internal, the Google error “restricted to users within its organization” means the operator signed in with an account outside the Workspace organization.
External fits when some operators sign in with addresses outside a single Workspace organization. The orchestrator’s allowlist is then the only gate, and the consent screen needs the Publish app step below.
3

Publish the consent screen

This step applies to the External audience only — an Internal app needs no publishing.On the Audience page, click Publish app to move the consent screen from testing to production.The three scopes this app requests are non-sensitive (openid, email, profile), so Google requires no verification and the publish takes effect immediately.Publishing clears two limits that testing mode imposes:
  • The 100-account cap on who can authenticate
  • The “unverified app” interstitial shown at sign-in
Your orchestrator’s allowlist stays the real access gate. Publishing widens who Google will authenticate, but the orchestrator still admits only allowlisted addresses, fail-closed — so it does not weaken access control.
4

Declare the scopes

On the Data Access page, click Add or remove scopes and select the three the orchestrator requests:
  • openid
  • .../auth/userinfo.email
  • .../auth/userinfo.profile
All three are non-sensitive, so no Google verification is required.
5

Create the OAuth client

Create OAuth client on the Overview page and Create client on the Clients page open the same form.The form asks for the application type first. The name and redirect URI fields appear only after you choose Web application.Give the client an internal name — this one isn’t shown to operators.Under Authorized redirect URIs, add two entries per orchestrator — one for admin sign-in and one for the MCP client flow:
Leave Authorized JavaScript origins empty. The orchestrator exchanges the authorization code server-side, so that field is unused.
Register both URIs. Admin sign-in working confirms only that its own callback is registered — the MCP callback is a separate entry, and omitting it fails every MCP client connection with redirect_uri_mismatch.Each URI must match byte for byte — https, no trailing slash. A mismatch fails at sign-in with the same error.Don’t add a localhost URI to a client that holds production credentials. If you want sign-in locally, create a separate client for it.
Create the client, then copy the Client ID and Client secret into GOOGLE_OAUTH_CLIENT_ID and GOOGLE_OAUTH_CLIENT_SECRET.

​
Wire the orchestrator

Alongside the provider credentials above, every orchestrator needs the callback base URL and the allowlist seed:
After your first SSO sign-in, click Save changes on /admin#access to adopt this seed as the stored list, then add any later operators there rather than in Fly secrets.
OAUTH_REDIRECT_BASE_URL must match the redirect URI you registered — the orchestrator builds the callback from it, so a mismatch produces the same failure as a mistyped URI.
Each variable is described in Environment variables.
Run one OAuth client per provider for the whole organization, in a GCP or Entra project owned by your admin group. Every orchestrator points at that same client.Adding an orchestrator is then two edits: register its two callback URIs on the existing client, and give it its own allowlist.

​
Add the orchestrator as a project connector

The /mcp endpoint can be added to claude.ai as a project connector, which needs one secret beyond the sign-in setup above. Without it, the connection fails at dynamic client registration with invalid_redirect_uri, before any sign-in screen appears. The registration endpoint accepts loopback callbacks by default, so Claude Code needs no equivalent configuration. A browser-based client such as claude.ai calls back over HTTPS, and that origin has to be allowlisted explicitly.
1

Allowlist the claude.ai origins

Set MCP_ALLOWED_REDIRECT_ORIGINS as a secret with the origins claude.ai registers from:
The callback claude.ai registers is https://claude.ai/api/mcp/auth_callback, and allowlisting its origin is all you do.
This is not the same as the provider redirect URIs you added earlier. Those let the orchestrator finish sign-in with Google or Microsoft.This allowlist decides which client origins may register with the orchestrator at all, which happens before any sign-in begins.
2

Add the connector in claude.ai

In claude.ai, add the orchestrator’s /mcp URL as a project connector and complete the sign-in. Registration now succeeds, and the flow continues to your configured Google or Microsoft sign-in.
Only the origins you list are accepted. Arbitrary HTTPS origins stay denied by design, so the allowlist is exactly the origins above unless you connect from somewhere else.
A connector survives access-token expiry on its own. The server issues refresh tokens, so a connected client refreshes silently in the background rather than sending you back through sign-in when its hourly access token expires.

​
The shared access code

ADMIN_ACCESS_CODE still works and is the right choice for local development, but it is deprecated for deployed orchestrators — it identifies nobody and cannot be revoked for one person. The admin UI is enabled when the access code or any sign-in provider is configured, so you can leave the code in place while operators move across, then remove it.

​
What’s next

Environment variables

Every sign-in variable, with its accepted values and defaults.

Admin UI reference

What each panel in the admin UI does once you’re signed in.