Inicio con Google, MFA centralizado y una ruta de identidad compartida para clientes

Qué significa la autenticación multifactor centralizada para las aplicaciones

La autenticación centralizada ofrece un lugar deliberado para verificar la identidad en todo el portafolio. Cuando una aplicación protegida recibe a una persona que no ha iniciado sesión, la dirige a auth.autosecurelogin.com. El servicio de identidad verifica la contraseña de la cuenta y el segundo factor requerido, y después devuelve a la persona al destino protegido original. El primer destino protegido es el centro de mando del portafolio en el dominio principal de Auto Secure Login.

Una aplicación de autenticación genera contraseñas temporales de un solo uso, conocidas como códigos TOTP. El servicio de identidad también puede admitir llaves de acceso o passkeys como una opción sólida de recuperación o inicio de sesión. Esto no coloca automáticamente una barrera frente a todos los productos. Los recursos de interés público, la información de productos, las páginas legales y las guías para búsqueda pueden seguir siendo públicas. Las cuentas, los portales de personal y las herramientas administrativas se conectarán una por una después de revisar compatibilidad, privacidad, recuperación y responsabilidad operativa.

El nuevo panel convierte trabajo disperso en una vista operativa

Un portafolio creciente de software personalizado puede ser difícil de administrar cuando cada aplicación tiene su propio estado de alojamiento, repositorio, página legal, etapa de publicación y siguiente acción. El panel privado actualmente sigue dieciocho proyectos de programación relevantes y treinta y nueve tareas revisadas. Comprueba la disponibilidad pública y una lista permitida de servicios del servidor, y combina esa información en vivo con una cola de trabajo organizada. Se excluye trabajo claramente ajeno a la programación para mantener el enfoque en la entrega de software.

El panel cubre Auto Secure Login, StubSafe, Aya, Outside Access, ASL Direct, Policy Lens, la orientación SOMB y DORA, APMSG, Pillow Pair, Kavanah Journal, HomelessHelper, Búsqueda de Doctores y NPI, Repo Runner, Sentinel, ASL Tunnel y Playwright Selector Toolkit. Cada tarjeta explica el producto, enlaza la aplicación y el repositorio correspondiente, muestra si la autenticación central está activa o planificada y enumera trabajo concreto que todavía requiere atención.

Las prioridades actuales son visibles sin afirmar que todo está terminado

El centro de mando diferencia una respuesta pública saludable del trabajo necesario para una publicación confiable. La aplicación de recibos de pago StubSafe y su servicio de reglas de nómina necesitan una revisión de estabilidad antes de avanzar con cuentas centralizadas. APMSG requiere diagnosticar el reinicio de su aplicación de mensajería y después completar una prueba de consentimiento y entrega. Kavanah Journal necesita revisar su servicio inactivo, su configuración de autenticación para producción y la recuperación de respaldos. Estos son hechos operativos, no afirmaciones de mercadeo.

La cola también registra preparación para producción que no aparece en una simple luz verde. ASL Direct todavía incluye activación de proveedores, llamadas supervisadas, responsabilidad operativa, revisión legal y de privacidad, firma de Android y validación de respaldos. Sentinel mantiene una lista documentada para activar la siguiente versión de monitoreo continuo. Outside Access, Repo Runner, Pillow Pair, HomelessHelper y las herramientas de datos públicos también tienen responsabilidades recurrentes de respaldo, calidad de datos, mensajería o verificación de versiones.

La seguridad depende de controles en capas y no de una sola pantalla

El panel escucha solamente en la interfaz local privada del Droplet y se publica mediante el servidor HTTPS existente. El servidor web pide al servicio de identidad que autorice cada solicitud del panel, incluidos sus archivos de JavaScript y estilos, antes de enviarla a la aplicación. La propia aplicación también rechaza solicitudes que no contengan una identidad verificada por el intermediario. Este diseño en capas reduce la posibilidad de que una ruta o un archivo estático evite accidentalmente el requisito de inicio de sesión.

La interfaz es deliberadamente de solo lectura. No puede reiniciar servicios, editar tareas, abrir bitácoras privadas ni cambiar la configuración de implementación. Así, la primera integración resulta útil sin convertir una página nueva en una superficie de control remoto. Esta actualización pública documenta la arquitectura y su valor comercial, pero excluye credenciales de cuentas, semillas de autenticación, llaves privadas, datos de clientes, detalles internos de red y decisiones protegidas del código fuente.

Próximos pasos para identidad y operaciones del portafolio

La siguiente tarea de autenticación es habilitar correo confiable para la recuperación de cuentas mediante una credencial dedicada de envío. Después se registrará una passkey como factor de respaldo y se probará la recuperación cifrada de la base de identidad. Con esas bases verificadas, una aplicación operativa controlada podrá convertirse en el siguiente piloto. Repo Runner u Outside Access son candidatos razonables porque sus flujos para usuarios autorizados se benefician de un acceso uniforme, aunque la selección final debe seguir una revisión de compatibilidad y funciones. El Centro de Mando ahora incluye un enlace directo para cambiar la contraseña en la pantalla de seguridad de la cuenta, y una visita directa al portal de identidad utiliza el Centro de Mando como destino predeterminado después del inicio de sesión.

Pillow Pair es ahora el primer piloto cliente registrado y puede avanzar a su conexión con Better Auth. StubSafe, APMSG y Kavanah Journal pueden continuar después de estabilizar sus servicios y cuentas. Las herramientas públicas como HomelessHelper, Búsqueda de Doctores y NPI, Policy Lens y Aya no necesitan exigir inicio de sesión para el uso público ordinario. El patrón útil es una protección selectiva: mantener accesible el contenido educativo y de descubrimiento, proteger datos personales u operativos y ofrecer a los administradores un lugar para entender el portafolio antes de decidir qué construir o reparar.

Una identidad compartida prepara el inicio con Google sin romper el acceso del personal

El acceso actual del personal sigue siendo adecuado para proteger rutas administrativas mediante el servidor web, pero no está diseñado para usar Google como proveedor de identidad externo. En lugar de reemplazar un inicio de sesión de dos factores que ya funciona o copiar un secreto de Google dentro de cada producto, Auto Secure Login ahora cuenta con un intermediario separado de OpenID Connect bajo el mismo dominio de autenticación. El intermediario ofrece a las aplicaciones con cuentas un emisor estándar, puntos de autorización y un modelo de funciones, mientras el Centro de Mando conserva su acceso actual.

La conexión con Google se divide de forma deliberada entre una base pública de la plataforma y una credencial privada de Google Cloud. El punto de identidad y el plan de integración pueden publicarse y probarse sin revelar un secreto. Para aceptar usuarios reales de Google, la persona responsable del proyecto en Google Cloud debe crear un cliente OAuth de tipo aplicación web, registrar exactamente la dirección de retorno del intermediario y solicitar solamente los alcances básicos openid, email y profile. El identificador y el secreto permanecen en configuración protegida del servidor, no en un repositorio, una publicación, una captura de pantalla o el código visible del navegador.

Este modelo admite más de una opción de acceso. Las cuentas de clientes podrán usar passkeys, códigos de aplicaciones de autenticación y códigos de recuperación. Las organizaciones que necesiten su propio proveedor podrán conectar Microsoft Entra ID u otro servicio compatible con OpenID Connect o SAML. El registro con correo y contraseña permanece en preparación hasta verificar recuperación por correo, aceptación de términos y procedimientos de soporte. Los mensajes SMS no son el factor de seguridad predeterminado porque existen opciones más resistentes al phishing.

Pillow Pair es la primera aplicación cliente registrada en el nuevo dominio de identidad. Su cliente confidencial del servidor utiliza una dirección de retorno exacta y exige PKCE con el método S256. La credencial generada se guarda solamente en configuración protegida del servidor. Conectar la interfaz actual de Better Auth es el siguiente cambio de código. StubSafe y APMSG permanecen detrás de reparaciones de servicio, mientras Kavanah Journal está saludable y su trabajo de identidad queda en cola después de la revisión de recuperación y respaldos.

Protección del panel Tunnel e informes operativos más actualizados

El panel ASL Tunnel ahora tiene un enlace directo desde el Centro de Mando privado y está protegido por el mismo límite de autenticación de dos factores para administradores que se usa en las operaciones de la plataforma. Una visita sin autenticar se redirige al acceso central del personal antes de mostrar cualquier control de Tunnel. Así, la consola operativa queda disponible desde un solo lugar sin convertirse en una superficie pública de administración.

El Centro de Mando ahora supervisa las dos partes de la base de identidad compartida: el servicio actual de autenticación del personal y el intermediario de identidad OpenID Connect para clientes. También muestra los grupos protegidos de administradores de plataforma, personal, clientes y aplicaciones, de modo que las integraciones futuras reciban funciones limitadas en lugar de una cuenta general con acceso total. Tunnel usa actualmente el límite de administrador del personal, mientras las aplicaciones cliente compatibles pueden adoptar el intermediario después de revisar sus flujos de cuenta.

La advertencia de Journal también se corrigió después de una comparación en vivo. Kavanah Journal estaba activo y en ejecución sin reinicios registrados del servicio, y su comprobación pública devolvió HTTP 200. Una tarea de reparación ya completada seguía apareciendo en la lista prioritaria porque el filtro no excluía el trabajo terminado de prioridad alta. Las tareas completadas ya no aparecen allí; el trabajo pendiente de preparación para publicación permanece visible como trabajo planificado y no como una falsa interrupción.

Las comprobaciones de aplicaciones se ejecutan automáticamente cada 60 segundos. Las solicitudes pasivas pueden reutilizar una instantánea del servidor durante un máximo de 45 segundos, pero el botón Actualizar estado ahora omite esa instantánea y ejecuta una comprobación inmediata. La página muestra la hora de la última revisión y este ritmo de actualización para que los operadores sepan si un resultado es reciente.