Authentication NEW

Swisblade can put a login in front of any public service — without a single line of auth code in your app. You declare auth in your stack.json, paste your OAuth credentials, and Swisblade runs a dedicated authentication proxy (a sidecar) in front of the service. Unauthenticated visitors are redirected to sign in; authenticated ones reach your app with their identity attached.

It works with any language or framework, because it runs at the infrastructure layer, not inside your code.

How it works

When a service declares auth, Swisblade injects a dedicated oauth2-proxy sidecar and wires it into the router with forward authentication:

Visitor → HTTPS → Traefik → (not logged in?) → oauth2-proxy → Google sign-in
                                    │
                              (logged in) → your app, with identity headers

• The /oauth2/* paths (sign-in page, callback, sign-out) are served by the sidecar.
• Every other request is checked. If there is no valid session, the visitor is redirected to the provider's login. If there is, the request reaches your app.
• Your app never sees the login flow — it only receives authenticated requests.

Enabling it

Add an auth block to a public app service:

{
  "name": "my-project",
  "services": {
    "api": {
      "type": "app",
      "source": { "repo": "github.com/you/api.git", "ref": "main" },
      "runtime": "node",
      "port": 3000,
      "public": true,
      "auth": {
        "provider": "google",
        "allowed_emails": ["@your-company.com"]
      }
    }
  }
}

auth fields

Field	Type	Default	Description
provider	string	—	Identity provider. Currently "google". Required.
client_id_secret	string	"GOOGLE_CLIENT_ID"	Name of the vault secret holding the OAuth client ID.
client_secret_secret	string	"GOOGLE_CLIENT_SECRET"	Name of the vault secret holding the OAuth client secret.
allowed_emails	string[]	any	Allowed email domains, e.g. ["@company.com"]. Omit to allow any account the provider authenticates.

note

allowed_emails currently restricts by domain (entries like @company.com). Allow-listing individual addresses is on the roadmap.

Setting up Google

1. In the Google Cloud Console, select or create a project.
2. Under Google Auth Platform, configure the consent screen (Branding: app name + support email; Audience: External, and add yourself under Test users while the app is in testing).
3. Under Clients, create an OAuth client ID of type Web application.
4. After you create the Swisblade project (the domain depends on the generated slug), set on the OAuth client:
   • Authorized redirect URI: https://<service>-<slug>.swisblade.com/oauth2/callback
   • Authorized JavaScript origin: https://<service>-<slug>.swisblade.com
5. Copy the Client ID and Client Secret, and add them to the project vault as GOOGLE_CLIENT_ID and GOOGLE_CLIENT_SECRET (see Environment Variables).

The session cookie secret is generated and managed for you — you don't need to provide it. If a required OAuth secret is missing, the deploy stops with a clear error instead of starting a broken proxy.

Reading the user's identity

Every authenticated request reaches your app with these headers:

Header	Contents
Authorization: Bearer <id_token>	The provider's signed ID token (a JWT).
X-Auth-Request-Email	The authenticated user's email.
X-Auth-Request-User	The provider's stable user id.

For simple cases, read X-Auth-Request-Email directly. For authorization (RBAC), verify the signed ID token in Authorization against the provider's public keys (JWKS) and map the identity to roles in your own logic — authorization is business logic, so it stays in your app.

Trust the signed token for authorization

The plain X-Auth-Request-* headers are convenient, but for anything security-sensitive verify the signed ID token (JWKS). A signed JWT cannot be forged; a plain header could be, depending on your network posture. The access token is intentionally not forwarded to your app.

Google ID tokens carry identity claims (email, name, subject, hosted domain) but no groups or roles — so with Google, your app maps email or domain to roles. Group-based roles from the identity provider will come with additional providers (Azure AD, Keycloak, generic OIDC).

What you don't have to do

• No auth libraries or SDKs.
• No login page, session handling, token refresh, or callback routes.
• No route guards — the whole service is protected at the edge.

Add auth, paste two secrets, deploy. That's it.