Openclaw SSO Integration: Enterprise Authentication Guide

Before you spend a week configuring SAML assertions for Openclaw, you should know: Openclaw has no native SSO. The gateway supports token-based auth, password auth, and trusted-proxy mode. That is the full list. The community requested native OIDC support in GitHub issue #4642, and the maintainers closed it as “not planned.” So if your enterprise security team requires single sign-on, you need to build it yourself using a reverse proxy and an external identity provider.

The pattern works, it takes about two hours to configure, and it integrates cleanly with Okta, Azure AD, Google Workspace, or any OIDC/SAML-compliant identity provider. This guide covers exactly how to do it.

---

What Openclaw Actually Supports for Authentication

The official gateway security docs describe three authentication modes:

Token-based auth is the default and recommended mode. You generate a long random bearer token with openclaw doctor --generate-gateway-token, store it in your config, and every client presents it on connection. The docs are blunt about the limitation: “Gateway HTTP bearer auth is effectively all-or-nothing operator access.” Everyone with the token gets the same permissions.

Password auth works the same way but uses a shared password instead of a token. Set gateway.auth.mode: "password" and store the password in the OPENCLAW_GATEWAY_PASSWORD environment variable. Same all-or-nothing access model.

Trusted-proxy auth is the mode that enables SSO. When you set gateway.auth.mode: "trusted-proxy", the gateway delegates authentication to an upstream reverse proxy. The proxy handles identity verification, and the gateway trusts the identity headers it receives. This is how you connect Openclaw to any enterprise identity provider.

The gateway binds to loopback by default (gateway.bind: "loopback"), which means only local clients can connect. Non-loopback binds expand the attack surface and require robust authentication, which makes the trusted-proxy pattern the right approach for any network-accessible deployment.

---

The Reverse Proxy SSO Pattern

Here is how the pieces fit together: your identity provider (Okta, Azure AD, Keycloak, Authentik) authenticates users, a reverse proxy (Nginx, Caddy, Traefik) sits in front of the Openclaw gateway, and the proxy passes verified identity headers downstream. Openclaw’s trusted-proxy mode reads those headers and accepts the connection.

This is the same pattern used by Grafana, Gitea, and dozens of other self-hosted tools that lack native SSO. It is well-understood, battle-tested, and adds minimal latency (typically under 5ms per request for the auth check).

Setting Up with Authentik or Keycloak

Both Authentik and Keycloak run as Docker containers alongside Openclaw (see our Docker deployment guide for container setup). Authentik is lighter and faster to configure for small teams. Keycloak has deeper enterprise features like fine-grained authorization and SAML identity brokering.

The setup has four steps:

1. Deploy the identity provider. Run Authentik or Keycloak via Docker Compose on the same host or network as Openclaw. Create a realm (Keycloak) or tenant (Authentik) for your organization.

2. Create an OAuth2/OIDC application. Register Openclaw as a client application in your IdP. Set the redirect URI to your reverse proxy’s callback endpoint. Record the client ID and client secret.

3. Configure the reverse proxy. Use Nginx with the auth_request module, Caddy with the forward_auth directive, or Traefik with the ForwardAuth middleware. The proxy intercepts every request to the Openclaw gateway, redirects unauthenticated users to the IdP login page, and passes identity headers (like X-Forwarded-User and X-Forwarded-Email) to Openclaw on successful auth.

4. Set Openclaw to trusted-proxy mode. Update your Openclaw config:

{
  gateway: {
    auth: { mode: "trusted-proxy" },
    trustedProxies: ["127.0.0.1", "10.0.0.0/8"],
    bind: "loopback"
  }
}

Configure trustedProxies with the IP addresses of your reverse proxy. Openclaw will only accept forwarded identity headers from these addresses. Keep bind: "loopback" so the gateway is never directly exposed to the network.

Integrating with Okta, Azure AD, or Google Workspace

If you use a cloud identity provider, the reverse proxy pattern is identical. The only difference is where you create the OIDC application:

• Okta: Create a new Web Application in the Okta admin console. Set the sign-in redirect URI to your proxy’s callback. Okta provides the issuer URL, client ID, and secret.
• Azure AD (Entra ID): Register an application in the Azure portal under App registrations. Configure the redirect URI. Azure provides the tenant ID, client ID, and client secret.
• Google Workspace: Create OAuth 2.0 credentials in the Google Cloud Console. Set the authorized redirect URI. Google provides the client ID and secret.

Each provider issues standard OIDC tokens. The reverse proxy validates the token, extracts the user identity, and forwards it to Openclaw. From Openclaw’s perspective, it does not matter which IdP issued the token.

For SAML 2.0 integration (required by some enterprise security policies), Keycloak or Authentik acts as a SAML-to-OIDC bridge. The enterprise IdP speaks SAML to Keycloak, and Keycloak speaks OIDC to your reverse proxy. This avoids the complexity of configuring SAML directly in the proxy layer.

---

Token-Based Auth for API Access

SSO covers human users accessing Openclaw through a browser or messaging client. But enterprise deployments also need programmatic access for CI/CD pipelines, webhook integrations, and internal tools that call the Openclaw API.

For these use cases, token-based auth remains the right approach. The key is managing tokens properly:

Generate tokens with sufficient entropy. Use openclaw doctor --generate-gateway-token or generate a 256-bit random string. Short tokens are vulnerable to brute-force attacks. The gateway is fail-closed by default: if no auth is configured, it refuses WebSocket connections.

Rotate tokens on a schedule. Token rotation requires four steps: generate a new token, update the gateway config, restart the gateway, update all remote clients. Plan for a brief service interruption or run a rolling restart if you have multiple instances behind a load balancer.

Separate hook tokens from gateway tokens. The official docs recommend using different tokens for webhook ingress and gateway auth. A compromised hook token should not grant full gateway access.

Store tokens in your secrets manager. Never hardcode tokens in config files checked into version control. Use HashiCorp Vault, AWS Secrets Manager, or your platform’s native secrets management. Inject tokens at runtime via environment variables. For more on token lifecycle, see our Openclaw OAuth setup guide.

CVE-2026-25253 (CVSS 8.8) demonstrated why token hygiene matters: a vulnerability in early 2026 allowed third-party Skills to exfiltrate API keys from the Openclaw environment. The patch landed in v2026.1.29, but the incident reinforced that static tokens are a liability if not rotated and isolated properly.

---

Session Management and Per-User Isolation

Openclaw’s session system is not traditional RBAC. Instead of roles and permissions, it uses session scoping to separate contexts between users. The dmScope setting controls how sessions are partitioned:

• main (default): All DMs share one session. Good for a single operator.
• per-channel-peer: Isolates sessions by channel and sender. Each user on each channel gets their own conversation context.
• per-peer: Each sender gets one session across all channels.
• per-account-channel-peer: Full isolation per account, channel, and sender. Use this for multi-team deployments where departments should not see each other’s interactions.

For enterprise SSO deployments, per-channel-peer or per-account-channel-peer is the right choice. Combined with the reverse proxy pattern, each authenticated user gets an isolated session with their own conversation history and tool access context.

DM access control adds another layer. The dmPolicy: "pairing" mode requires unknown senders to complete a pairing handshake: they receive a one-time code that expires after one hour with a three-request cap. An administrator approves pairings with openclaw pairing approve. The allowlist mode blocks unknown senders entirely. For full audit trail setup, see our Openclaw audit logging guide.

One limitation to be transparent about: Openclaw “does not claim hostile multi-tenant isolation on one shared gateway.” The session system is designed for a trusted-operator model. If you need hard tenant boundaries where users cannot access each other’s data even with elevated privileges, you need separate Openclaw instances per team (see our enterprise deployment guide).

---

Frequently Asked Questions

Does Openclaw support SSO natively?

No. As of early 2026, Openclaw supports token-based auth, password auth, and trusted-proxy mode. There is no built-in SAML or OIDC provider. The community requested native OIDC in GitHub issue #4642, and it was closed as “not planned.” The recommended approach is using an external identity provider with a reverse proxy in trusted-proxy mode.

How long does it take to set up SSO for Openclaw?

About two hours if you already have an identity provider running. The work breaks down to: 30 minutes deploying Authentik or Keycloak (if needed), 30 minutes configuring the OIDC application, 30 minutes setting up the reverse proxy, and 30 minutes testing and hardening. If you are connecting to an existing Okta or Azure AD instance, skip the first step.

Can I use Azure AD with Openclaw?

Yes, through the reverse proxy pattern. Register Openclaw as an application in Azure portal, configure the redirect URI for your proxy, and set up Nginx/Caddy/Traefik with the ForwardAuth middleware. Azure AD handles authentication, and the proxy passes the verified identity to Openclaw in trusted-proxy mode.

What happens if the identity provider goes down?

Users cannot authenticate new sessions. Existing sessions with active WebSocket connections continue working until the connection drops. This is why running a local identity provider (Authentik, Keycloak) on the same infrastructure as Openclaw reduces the blast radius compared to depending on a cloud IdP for every authentication event.

How do I enforce MFA on Openclaw access?

Configure MFA in your identity provider, not in Openclaw. Okta, Azure AD, Keycloak, and Authentik all support TOTP, WebAuthn (FIDO2 hardware keys), and push notifications. Since the reverse proxy delegates auth to the IdP, MFA enforcement happens before the user reaches the Openclaw gateway.

How do I handle API authentication for CI/CD pipelines?

Use token-based auth for programmatic access. Generate a dedicated gateway token for each pipeline or service, store it in your secrets manager, and rotate on a 90-day schedule. Do not reuse the same token across multiple services. If one token is compromised, you only need to rotate the affected integration.

---

Key Takeaways

• Openclaw has no native SSO. The path to enterprise single sign-on is the trusted-proxy auth mode combined with an external identity provider and a reverse proxy.
• Use Authentik or Keycloak for self-hosted identity, or connect to existing Okta, Azure AD, or Google Workspace instances via standard OIDC.
• Token-based auth is still necessary for API consumers and CI/CD pipelines. Rotate tokens, separate hook tokens from gateway tokens, and use a secrets manager.
• Session isolation via dmScope settings provides per-user separation, but it is not hostile multi-tenant isolation. For hard boundaries between teams, deploy separate Openclaw instances.

If your team is evaluating Openclaw for enterprise use and needs help designing the authentication architecture, reach out to SFAI Labs for a technical consultation.