Autenticación

ObjectOS utiliza el complemento de autenticación de ObjectStack, basado en Better Auth. La autenticación es local al proyecto: cada proyecto tiene sus propias tablas de identidad y su propio alcance de sesión.

Qué se admite

Según la aplicación empaquetada y los ajustes habilitados, ObjectOS puede admitir:

• inicio de sesión con correo electrónico y contraseña;
• gestión de sesiones;
• restablecimiento de contraseña y verificación de correo electrónico;
• proveedores de OAuth social como Google, GitHub, Microsoft y Apple;
• OIDC/SSO empresarial como Okta, Entra ID, Keycloak y Ping;
• autenticación de dos factores;
• passkeys/WebAuthn;
• enlaces mágicos;
• flujo de dispositivos CLI/navegador.

Secreto requerido

Configura:

OS_AUTH_SECRET=replace-with-a-strong-random-secret

ObjectOS deriva un secreto estable por proyecto a partir de este valor y del id del entorno del proyecto. Esto significa que:

• las sesiones sobreviven a los reinicios de contenedores;
• los tokens de un proyecto no se pueden reutilizar en otro proyecto;
• rotar OS_AUTH_SECRET invalida las sesiones.

Consulta Environment variables para ver la lista completa de ajustes relacionados con la autenticación, incluido el alias heredado AUTH_SECRET.

Aislamiento de sesiones

En despliegues con varios proyectos, las cookies tienen su alcance limitado al nombre de host del proyecto. ObjectOS evita intencionadamente las cookies amplias de dominio raíz para las sesiones de proyecto. Esto impide que una sesión se filtre entre proyectos de distintos clientes.

Inicio de sesión social

Configura las credenciales del proveedor mediante variables de entorno o ajustes del sistema, según cómo el paquete de la aplicación exponga la configuración de autenticación.

Las URL de devolución de llamada del proveedor dependen del tipo de proveedor. ObjectStack expone dos rutas de devolución de llamada distintas y no son intercambiables:

Ejemplos:

https://crm.example.com/api/v1/auth/callback/google
https://crm.example.com/api/v1/auth/callback/microsoft
https://crm.example.com/api/v1/auth/oauth2/callback/okta
https://crm.example.com/api/v1/auth/oauth2/callback/entra

Configura la URI de redirección correspondiente en el registro de aplicación del proveedor de identidad antes de habilitar el proveedor en ObjectOS.

OIDC/SSO empresarial

Los proveedores OIDC se registran como proveedores OAuth2 genéricos y usan la ruta /api/v1/auth/oauth2/callback/<provider>. Una configuración típica requiere:

Para los despliegues de clientes, prefiere las URL de descubrimiento OIDC en lugar de endpoints de autorización/token/userinfo configurados manualmente.

SSO de plataforma

En despliegues conectados a la nube, ObjectOS puede usar el inicio de sesión del plano de control como proveedor de SSO de plataforma. Un creador que ya haya iniciado sesión en el plano de control puede aprovisionarse en el entorno de ejecución de un proyecto sin crear una cuenta local del proyecto independiente.

Esto requiere que el plano de control y ObjectOS compartan el mismo secreto base OS_AUTH_SECRET. Deshabilita el SSO de plataforma solo cuando el cliente quiera que cada proyecto tenga un límite de inicio de sesión completamente independiente.

Comprobaciones operativas

Antes de producción:

• confirma que los tokens caducados devuelven 401;
• confirma que el cierre de sesión revoca la sesión activa;
• confirma que el restablecimiento de contraseña revoca otras sesiones si la política lo requiere;
• confirma que las URL de devolución de llamada coinciden con el dominio público del proyecto;
• confirma que los orígenes de confianza incluyen solo dominios aprobados;
• confirma que OS_AUTH_SECRET se almacena en un gestor de secretos, no en el código fuente.

Próximos pasos

La autenticación establece quién es un usuario. Para controlar a qué puede acceder una vez que ha iniciado sesión, consulta Permissions. Para clientes que no son navegadores y para el acceso de máquina a máquina, consulta API access.