Cómo iniciar autenticación externa
Abre el flujo OAuth/OIDC de un proveedor configurado. Antylogic no crea sesión en este punto: genera state, conserva datos temporales en cookies de 10 minutos y redirige al authorization_endpoint del proveedor.
En este artículo
Usa esta guía cuando soporte u operaciones necesiten comprobar que el inicio público de autenticación externa está disponible para la demo o para un runtime configurado.
En la demo española, el caso más estable es native-local. Proveedores como google, microsoft o apple dependen de configuración adicional y no deben documentarse como botones visibles si el runtime no los habilita.
La acción termina al emitir una redirección 302. La creación o recuperación de sesión pertenece al callback auth.oauth.complete.
Antes de empezar
- Debe existir un registro auth_providers para el código usado en la ruta.
- El proveedor debe estar enabled=true.
- El proveedor debe tener authorization_endpoint efectivo y client_id.
- El cliente debe aceptar y conservar cookies temporales bajo Path=/api/app hasta el callback.
- Para capturas de la demo ES, usar native-local salvo que el runtime configure y habilite un proveedor externo real.
Instrucciones
- 1.
Confirmar proveedor disponible
Antes de abrir el enlace, confirma que el proveedor existe y está habilitado. Para Grupo Marea Demo, usa native-local como proveedor por defecto y evita documentar Google, Microsoft o Apple como opciones visibles sin evidencia del runtime.
- 2.
Abrir el enlace de inicio
Abre GET /api/app/auth/authorize/{provider}. La acción no recibe JSON ni formulario; puede recibir return_to, client_id y scopes por query string. El ejemplo estable es /api/app/auth/authorize/native-local?return_to=/auth/login.
- 3.
Dejar que Antylogic prepare el estado
El backend normaliza el código del proveedor, genera state, construye redirect_uri hacia /api/app/auth/callback/{provider} y escribe cookies temporales de 10 minutos para state, client_id y, cuando aplica, return_to, scopes y pkce_verifier.
- 4.
Seguir la redirección inicial
Si el proveedor está configurado, Antylogic responde 302 Found hacia el authorization_endpoint con response_type=code, client_id, redirect_uri, scope y state. En proveedores nativos o sin client_secret también añade PKCE S256.
- 5.
Continuar fuera de esta acción
Después de la redirección, el usuario completa el login en el proveedor o login upstream. El callback necesita recuperar las cookies temporales para validar state y resolver el destino posterior.
Validaciones y límites
- Solo se acepta método GET.
- {provider} es obligatorio y se normaliza a minúsculas sin espacios externos.
- No se requiere sesión, token ni membership para iniciar el flujo.
- El proveedor debe existir, estar enabled=true y tener authorization_endpoint y client_id efectivos.
- El query param scopes se conserva para el callback, pero no cambia el scope enviado al proveedor upstream.
- Si no se envía client_id, se usa el cliente OAuth por defecto; si está vacío, cae a antylogic-web.
- Las cookies temporales expiran en 10 minutos y se escriben con Path=/api/app, HttpOnly y SameSite=Lax.
- Si el proveedor está deshabilitado o incompleto, la respuesta inmediata es 400; si falta provider, es 404; si el método no es GET, es 405.
- La acción no expone client_secret y no crea usuario ni sesión.
Resultado esperado
Antylogic deja preparado el estado OAuth/OIDC y entrega el flujo al proveedor mediante 302. Si el cliente conserva las cookies temporales, el callback podrá validar state y completar la sesión en auth.oauth.complete.