Autenticacion NUEVO

Swisblade puede poner un login delante de cualquier servicio publico — sin una sola linea de codigo de auth en tu app. Declaras auth en tu stack.json, pegas tus credenciales OAuth, y Swisblade corre un proxy de autenticacion dedicado (un sidecar) delante del servicio. Los visitantes no autenticados se redirigen al login; los autenticados llegan a tu app con su identidad adjunta.

Funciona con cualquier lenguaje o framework, porque corre a nivel de infraestructura, no dentro de tu codigo.

Como funciona

Cuando un servicio declara auth, Swisblade inyecta un sidecar dedicado de oauth2-proxy y lo conecta al router con forward authentication:

Visitante → HTTPS → Traefik → (no logueado?) → oauth2-proxy → login de Google
                                    │
                              (logueado) → tu app, con headers de identidad

• Las rutas /oauth2/* (pagina de login, callback, logout) las sirve el sidecar.
• Cada otra request se verifica. Si no hay sesion valida, el visitante se redirige al login del proveedor. Si la hay, la request llega a tu app.
• Tu app nunca ve el flujo de login — solo recibe requests autenticados.

Como activarlo

Agrega un bloque auth a un servicio app publico:

{
  "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": ["@tu-empresa.com"]
      }
    }
  }
}

Campos de auth

Campo	Tipo	Default	Descripcion
provider	string	—	Proveedor de identidad. Actualmente "google". Requerido.
client_id_secret	string	"GOOGLE_CLIENT_ID"	Nombre del secret en la boveda con el client ID de OAuth.
client_secret_secret	string	"GOOGLE_CLIENT_SECRET"	Nombre del secret en la boveda con el client secret de OAuth.
allowed_emails	string[]	cualquiera	Dominios de email permitidos, ej. ["@empresa.com"]. Omitir para permitir cualquier cuenta que el proveedor autentique.

nota

allowed_emails por ahora restringe por dominio (entradas tipo @empresa.com). El allow-list de emails individuales esta en el roadmap.

Configurar Google

1. En la Google Cloud Console, selecciona o crea un proyecto.
2. En Google Auth Platform, configura la pantalla de consentimiento (Branding: nombre de app + email de soporte; Audience: External, y agregate en Test users mientras la app este en testing).
3. En Clients, crea un OAuth client ID de tipo Web application.
4. Despues de crear el proyecto en Swisblade (el dominio depende del slug generado), configura en el OAuth client:
   • Authorized redirect URI: https://<servicio>-<slug>.swisblade.com/oauth2/callback
   • Authorized JavaScript origin: https://<servicio>-<slug>.swisblade.com
5. Copia el Client ID y el Client Secret, y agregalos a la boveda del proyecto como GOOGLE_CLIENT_ID y GOOGLE_CLIENT_SECRET (ver Variables de Entorno).

El secret de la cookie de sesion se genera y administra solo — no tenes que proveerlo. Si falta un secret de OAuth requerido, el deploy se frena con un error claro en lugar de arrancar un proxy roto.

Leer la identidad del usuario

Cada request autenticado llega a tu app con estos headers:

Header	Contenido
Authorization: Bearer <id_token>	El ID token firmado del proveedor (un JWT).
X-Auth-Request-Email	El email del usuario autenticado.
X-Auth-Request-User	El id estable del usuario en el proveedor.

Para casos simples, lee X-Auth-Request-Email directo. Para autorizacion (RBAC), verifica el ID token firmado del header Authorization contra las claves publicas del proveedor (JWKS) y mapea la identidad a roles en tu propia logica — la autorizacion es logica de negocio, asi que queda en tu app.

Confia en el token firmado para autorizacion

Los headers planos X-Auth-Request-* son comodos, pero para algo sensible verifica el ID token firmado (JWKS). Un JWT firmado no se puede falsificar; un header plano si, segun tu postura de red. El access token no se reenvia a tu app, a proposito.

Los ID tokens de Google traen claims de identidad (email, nombre, subject, hosted domain) pero no grupos ni roles — asi que con Google, tu app mapea email o dominio a roles. Los roles por grupo del proveedor de identidad vendran con proveedores adicionales (Azure AD, Keycloak, OIDC generico).

Lo que NO tenes que hacer

• Ninguna libreria ni SDK de auth.
• Ninguna pagina de login, manejo de sesion, refresh de tokens ni rutas de callback.
• Ningun guard de rutas — todo el servicio esta protegido en el borde.

Agregas auth, pegas dos secrets, deploy. Eso es todo.