Multi-app SSO

Add a second application to an existing login session.

This example starts from one protected application and adds a second route behind the same authentication provider. That is what creates SSO: the provider and the shared cookie domain are already in place, and the second route reuses the same Gate One session.

Changing the provider alone does not create SSO. Adding a route alone does not create SSO either. The two routes must use the same provider and share the same cookie domain.

File

examples/sso-multi-apps/routes.json

{
  "authProvider": {
    "type": "oidc",
    "issuer": "https://auth.example.com/realms/company",
    "clientId": "gate-one",
    "clientSecretEnv": "OIDC_CLIENT_SECRET",
    "loginBaseUrl": "https://login.example.com",
    "cookieDomain": "example.com"
  },
  "routes": [
    {
      "host": "app.example.com", "path": "/*", "frontend": true,
      "backend": "http://app:8080", "auth": {}
    },
    {
      "host": "reports.example.com", "path": "/*", "frontend": true,
      "backend": "http://reports:8080", "auth": {}
    }
  ]
}

The second reports.example.com route is the only addition needed for SSO, because it is under the same cookieDomain and uses the default provider.

Run it

The packaged demo runs both applications and Gate One against a local OIDC provider (Docker Compose):

cd gate-one-src/deploy/local/sso-multi-apps
BIN_DIR=~/gate-one-bin ./run.sh

The script prints the URLs and stops with ./run.sh down. See [deploy/local/sso-multi-apps](https://github.com/clad-one/gate-one/tree/main/deploy/local/sso-multi-apps) for the stack and its README.

To run it by hand instead:

export OIDC_CLIENT_SECRET=...
gate-one -check -config routes.json
gate-one -config routes.json

Register https://login.example.com/auth/callback at the identity provider. Point DNS (or your test hosts file) for app.example.com, reports.example.com and login.example.com at Gate One.

What to observe

  1. Open https://app.example.com; log in.

  2. Open https://reports.example.com in the same browser.

  3. The second host must not redirect to the identity provider: the shared example.com session cookie is reused.

Why it works

  • cookieDomain: "example.com" lets both hosts share the session cookie.

  • Both routes use the same authProvider and therefore the same issuer and session key.

  • This example runs a single Gate One instance, so the default bbolt session/revocation store is enough.

  • The second visit does not redirect to the identity provider.

Note

  • The applications must share a parent domain. app.company.com and app.other.com cannot share a cookie.

  • On a single instance, a logout revokes the session for the next request. For several replicas, see High Availability.

  • The applications can stay public: remove "auth": {} from one route. Only that route becomes anonymous.

Next

If you need several Gate One replicas, use High Availability. If your users come from several identity providers, see Keycloak with Google or Embedded IAM.