El despliegue ahora abarca todo el portafolio de Auto Secure Login
El servicio de identidad compartida fue diseñado para más de un producto. Pillow Pair demostró el primer recorrido completo con OpenID Connect, pero el mismo intermediario debe admitir distintos tipos de aplicaciones sin obligar a que cada herramienta pública tenga una pantalla de acceso. El portafolio incluye servicios de información pública, aplicaciones privadas para consumidores, sistemas de operaciones, interfaces API, procesos en segundo plano, aplicaciones web progresivas y un complemento Android del Centro de Mando. El nuevo manifiesto clasifica cada aplicación por público, superficie, estado, proveedor de identidad y página de términos.
Las herramientas públicas como Aya, Policy Lens, la guía SOMB y DORA, HomelessHelper, la búsqueda de médicos y NPI y el sitio bilingüe principal permanecen públicas por diseño. Outside Access, ASL Direct, Repo Runner y Sentinel están en cola porque cada uno necesita revisar su autorización y recuperación. StubSafe y APMSG continúan detrás de controles de estabilidad. El Centro de Mando y ASL Tunnel conservan su protección actual para el personal. Esta secuencia evita que el inicio central reduzca acceso, afecte la visibilidad en buscadores o esconda trabajo pendiente.
Entregado en esta actualización
- Manifiesto de dominios, públicos, términos y estado de cada aplicación
- Páginas públicas y de posicionamiento disponibles sin cuenta
- Autorización específica antes de conectar aplicaciones en cola
- Pillow Pair es el primer piloto, no el límite del programa
Kavanah Journal se convierte en el segundo cliente OpenID Connect compartido
Kavanah Journal ahora incluye un proveedor opcional Continuar con Auto Secure Login en su experiencia de Auth.js. La aplicación solicita únicamente openid, email y profile al intermediario compartido, usa el flujo de código con PKCE y verificación de estado y regresa por una sola dirección exacta del dominio Journal. El emisor, identificador y secreto deben existir juntos dentro de configuración protegida. Si el proveedor no está configurado, la interfaz no anuncia un botón inútil. Los textos en inglés y español explican claramente las alternativas.
El Journal conserva una ruta directa y separada para autorizar Google Fotos y Drive. Esos permisos más amplios no pertenecen a un token de identidad de toda la plataforma, por lo que ambas rutas siguen distintas. Auto Secure Login establece la identidad de la cuenta; la autorización directa de Google permite al Journal usar los servicios seleccionados por la persona. Los tokens de acceso y actualización del intermediario se eliminan en vez de copiarse a la sesión del navegador. Así otro producto no hereda permisos de almacenamiento por usar el mismo acceso central.
Entregado en esta actualización
- Retorno exacto del Journal con PKCE y verificación de estado
- Permisos compartidos limitados a openid, email y profile
- Autorización directa de Google Fotos y Drive separada
- Tokens del intermediario fuera del código del navegador
Doce decisiones permiten comprobar mejor el estado de seguridad
El Centro de Mando ahora presenta una lista de doce puntos basada en las preguntas necesarias para un despliegue responsable. Registra la arquitectura de varios repositorios, tipos de plataforma, dominios e identificadores, límites de sesiones, recuperación, clases de usuarios, revisión de jurisdicción, diferencia entre autenticación y prueba de identidad, acciones con verificación adicional, política de dispositivos, accesibilidad, soporte y capacidades del proveedor. Cada elemento muestra un estado sencillo como activo, documentado, en curso o revisión necesaria, en lugar de resumir todo con una sola luz verde.
La lista también explica límites importantes. El acceso central confirma control de una cuenta; no afirma prueba de identidad gubernamental, licencia profesional ni identificación biométrica. Una passkey puede usar la huella, el rostro o el PIN local de un dispositivo, pero Auto Secure Login no recibe ni almacena esa plantilla. Exportaciones sensibles, cambios de pago, mensajes, modificaciones de funciones y acciones destructivas todavía necesitan reglas específicas. Los productos de Colorado requieren revisión de retención, edad, consentimiento, accesibilidad y requisitos de su sector antes del registro público.
Entregado en esta actualización
- Doce decisiones visibles sobre arquitectura, recuperación y operaciones
- La autenticación no se presenta como prueba legal de identidad
- Sin almacenamiento central de plantillas faciales o de huellas
- Revisión legal y verificación adicional por producto
La validación protege la ruta antes del cambio en producción
El cambio del Journal superó validación estricta de TypeScript, resolución de código, orden de migraciones, búsqueda de secretos, 71 pruebas de la aplicación, 16 pruebas de nube privada y una compilación optimizada de Next.js. El árbol de dependencias también se actualizó cuando apareció un aviso nuevo de procesamiento de imágenes: Next.js pasó al parche compatible actual y usa la versión corregida de Sharp declarada por la aplicación en vez de instalar la copia opcional vulnerable. Las advertencias de estilo existentes siguen documentadas y no se introdujeron errores nuevos.
El registro en producción creó el cliente del Journal sin imprimir su secreto, lo cargó mediante un archivo legible solo por root y conservó la base de datos existente antes de compilar beta.14 en el Droplet. El punto de salud en vivo informa la nueva versión y la base de datos conectada. Auth.js inicia ahora la autorización en el intermediario central con el cliente kavanah-journal, la dirección exacta, solo openid email profile y un reto PKCE S256. Una persona todavía debe iniciar sesión, confirmar la vinculación prevista de cuentas y probar recuperación antes de considerar el piloto listo para uso amplio. La actualización del Centro de Mando también reveló una alerta independiente: una regla de rotación de Repo Runner duplicaba la regla general de Nginx. El archivo redundante se respaldó, toda la configuración pasó la validación, la rotación terminó correctamente y el Droplet volvió al estado saludable sin servicios fallidos.
Entregado en esta actualización
- 87 pruebas automatizadas de aplicación y nube privada aprobadas
- Salud de beta.14, base de datos y redirección compartida verificadas
- El Centro de Mando muestra 12 puntos y recursos saludables del Droplet
- Vinculación de cuenta y recuperación requieren aceptación humana