Features on Gate One

SSO across your apps

Mon, 01 Jan 0001 00:00:00 +0000

Useful if you want to…

give users one login for several applications;
keep the applications untouched: no SDK, no OIDC library, no frontend patch;
share a session between app.example.com, reports.example.com and similar hosts;
revoke a session centrally and have every application refuse it on the next request.

Gate One is a reverse proxy: the application still receives a normal HTTP request. It never sees a token unless you ask for it.

SSO across different domains

Mon, 01 Jan 0001 00:00:00 +0000

Useful if you want to…

give users one login across app-a.com and app-b.fr;
keep one cookie per domain instead of trying to share a cookie across unrelated registrable domains;
declare the OIDC/client/session settings once and avoid divergent copies;
declare the application route body once when the backend is the same.

Gate One cannot set one cookie for app-a.com and app-b.fr: browsers reject a Domain that is not a suffix of the current host. Cross-TLD SSO therefore relies on the IdP session, exactly like the multi-subdomain case relies on cookieDomain.

Multiple identity providers

Mon, 01 Jan 0001 00:00:00 +0000

Useful if you want to…

accept users from several identity providers (Google, Microsoft, GitHub, a corporate directory, …);
keep one issuer and one login surface for Gate One;
centralize user policy, roles and federation in an existing IAM;
avoid adding another identity service to the platform.

Protect APIs and MCP tools

Mon, 01 Jan 0001 00:00:00 +0000

Useful if you want to…

expose an API only to authenticated users, with roles, scopes or claim conditions per route;
accept machine clients with a bearer JWT, validated locally against a JWKS;
expose MCP tools with the OAuth protected-resource metadata clients expect (resource/audience, scope, tool list);
keep the browser session and the machine token planes separate.

Embedded IAM

Mon, 01 Jan 0001 00:00:00 +0000

Useful if you want to…

federate several IdPs without running Keycloak or another external IAM;
keep one OIDC issuer and one login surface for Gate One;
normalize IdP-specific groups, roles and claims into one vocabulary;
assign roles/scopes/claims to local and federated users;
stay lightweight: one Go binary, one JSON file, Redis optional for multi-instance state.

cladone-auth is optional. It is a small OIDC issuer and user directory, not a full identity provider.

Expose REST APIs and MCP servers as MCP tools

Mon, 01 Jan 0001 00:00:00 +0000

Useful if you want to…

give MCP clients (an assistant, an IDE, an agent) a governed tool surface over services that do not speak MCP;
expose a documented REST API as MCP tools without writing a server;
proxy an existing MCP server and restrict which tools it exposes;
aggregate several services under one endpoint with its own audience, scope and identity rules.

Call services with the user's credentials

Mon, 01 Jan 0001 00:00:00 +0000

Useful if you want to…

let a route or an MCP tool call an external API as the user, not as a shared service account;
keep the provider’s client secret out of Gate One;
let every user reach the upstream with their own rights;
give users a page where they connect, pause and erase those services.

Horizontal scaling

Mon, 01 Jan 0001 00:00:00 +0000

Useful if you want to…

run more than one Gate One instance behind a load balancer;
survive the loss of one replica without losing the login;
spread load across several replicas;
keep logout and revocation effective across every replica.

Why a single instance is simpler

A single Gate One instance keeps its OIDC session/revocation state in a local bbolt file. That is enough for one instance, and it needs no Redis.

bbolt is local to the instance. It cannot be shared safely by several Gate One replicas: a logout or back-channel revocation recorded on one node would not be visible to the others. That is why horizontal scaling requires a shared store.

Injectable UX

Mon, 01 Jan 0001 00:00:00 +0000

Useful if you want to…

show who is logged in and a logout button on an application you cannot modify;
turn a plain 401 into a login tab that replays the request after login, without a page reload;
hide or gate controls by role, scope or claim client-side, even when the markup is fixed;
add a banner, a stylesheet, a script or a PWA manifest per route;
show a readable page or a banner when the gateway itself refuses a request on identity (403), while keeping the JSON 403 for fetch().

The application source does not change. Gate One injects a small guard script and, optionally, an operator-provided bundle.

Bring your own account panel

Mon, 01 Jan 0001 00:00:00 +0000

Useful if you want to…

remove the top-edge user badge from an application you control;
show the signed-in user, roles, scopes or claims inside your own burger menu or side panel;
keep Gate One’s login guard, SSO session, logout and route policy;
keep the account UI consistent with the rest of the application.

Gate One does not need to render the account UI. The built-in badge is only a client of the same session probe your application can read.

Usage events and plugins

Mon, 01 Jan 0001 00:00:00 +0000

Useful if you want to…

meter or audit usage without putting code on the request path;
keep operational metrics (auth failures, errors, request counts) in your own system;
integrate a commercial or closed-source extension without granting it access to tokens or identities;
survive a plugin outage without losing the events you declared durable.

Events are produced only for subscribed types. If no plugin subscribes to request, Gate One produces no request event at all. Free/self-hosted Gate One is operational-only: it ships no commercial metering.

Cloudflare Turnstile

Mon, 01 Jan 0001 00:00:00 +0000

Useful if you want to…

stop bots from submitting a public form without changing the application;
protect an application that has no authentication and no form (a public tool, an API-driven frontend) — the page or only its expensive action;
add the same check to several pages and hosts from one place;
keep the widget working on a page Gate One already proxies.

The block is platform-wide: one configuration entry, every matching page gets the widget or the challenge, every matching request is checked with Cloudflare Siteverify before the backend.