Pillow Pair es el primer cliente OpenID Connect en vivo del portafolio
Pillow Pair ahora conecta su experiencia actual de cuentas con el servicio de identidad compartido de Auto Secure Login. Una persona que usa la web puede elegir Continuar con Auto Secure Login en inglés o español, pasar a la pantalla central de autorización y regresar por la dirección registrada del producto después de iniciar sesión correctamente. La aplicación consulta a su propio servidor antes de mostrar la opción, evitando que aparezca un botón sin funcionamiento cuando la configuración protegida no está disponible.
La integración utiliza descubrimiento de OpenID Connect, un cliente confidencial del servidor, el flujo de código de autorización y PKCE con el método S256. La dirección de retorno está limitada a la aplicación web de Pillow Pair y no usa un comodín amplio. El acceso existente con correo y contraseña y el modo de invitado permanecen disponibles. El inicio en aplicaciones móviles nativas continúa reservado hasta implementar y probar un regreso seguro mediante el navegador del sistema y enlaces de aplicación.
Entregado en esta actualización
- Acción bilingüe de inicio central en la aplicación web de Pillow Pair
- Dirección exacta, descubrimiento OpenID Connect y protección PKCE
- Acceso existente con correo y contraseña y modo de invitado conservados
- Inicio nativo reservado para una versión con retorno seguro
La política central añade opciones más fuertes sin eliminar las contraseñas
La política compartida mantiene como base práctica una cuenta con usuario y contraseña vinculada a un correo verificado. Las passkeys, los códigos de aplicaciones de autenticación y los códigos de recuperación son métodos adicionales. Una passkey puede estar protegida por la huella, la comprobación facial o el PIN que ya existe en un teléfono o computadora, pero Auto Secure Login no recopila ni guarda huellas, imágenes faciales, escaneos de iris u otras plantillas biométricas. El dispositivo realiza la comprobación local y devuelve una prueba criptográfica.
El intermediario de identidad está configurado para passkeys detectables y códigos de recuperación, sin quitar las alternativas de contraseña y autenticador. El registro público, la verificación por correo y el restablecimiento de contraseña por correo siguen siendo controles de lanzamiento hasta probar en conjunto la entrega confiable, la aceptación de términos y los procedimientos de soporte. Así no se anuncia una recuperación antes de demostrar que la persona recibirá el mensaje y comprenderá el siguiente paso.
Entregado en esta actualización
- Las cuentas con contraseña permanecen como base
- Passkeys, códigos de autenticador y recuperación opcionales
- Sin recopilación central de plantillas biométricas
- Registro público y recuperación por correo bajo controles de lanzamiento
Una Capa de Confianza registra evidencia de seguridad sin guardar secretos
El repositorio de la plataforma incluye ahora un contrato reutilizable y versionado para eventos del ciclo de identidad. Puede describir creación de cuentas, autenticaciones correctas o fallidas, cierre de sesión, cambios de contraseña, registro de passkeys, inscripción de autenticadores y uso de códigos de recuperación. El mismo contrato reserva recibos compatibles para futura aceptación de términos y consentimiento de mensajería, permitiendo un formato común en lugar de bitácoras distintas para cada aplicación.
El contrato rechaza contraseñas, tokens de sesión, códigos temporales, semillas de autenticadores, valores de recuperación, material WebAuthn sin procesar y registros biométricos dentro de los metadatos. Los eventos de identidad y administración también tienen retención limitada, y se desactivaron las representaciones administrativas detalladas. Estos límites conservan evidencia operativa útil y reducen el riesgo de convertir una bitácora de diagnóstico en otro almacén de material de autenticación.
Entregado en esta actualización
- Eventos versionados de identidad para productos compatibles
- Recibos futuros de términos y mensajería en el mismo modelo
- Rechazo de secretos, autenticadores sin procesar y datos biométricos
- Retención limitada para revisiones prácticas de seguridad
La verificación en vivo distingue una función configurada de la inscripción del usuario
El Centro de Mando ahora diferencia una capacidad de la plataforma de la preparación completada por cada persona. Las passkeys pueden estar configuradas en el servicio y aun requerir que cada usuario registre y pruebe un dispositivo. Los códigos de recuperación pueden estar disponibles y todavía necesitar que cada titular genere, guarde y pruebe su conjunto. Esta distinción evita que un indicador verde se convierta en una afirmación incorrecta de que todos terminaron su preparación de recuperación.
El servicio de Pillow Pair funciona desde una versión identificable, carga su identidad cliente desde configuración protegida e informa que el inicio central está habilitado. Una prueba pública devolvió una dirección de autorización del intermediario con el retorno exacto de Pillow Pair y el reto PKCE. El cliente OAuth web privado de Google ya está configurado y la página pública del intermediario muestra el proveedor Google. Falta una prueba de inicio de sesión real y vinculación de cuenta antes de considerarlo listo para producción. Los siguientes productos se conectarán uno por uno después de revisar cuentas, funciones, recuperación y estabilidad.
Entregado en esta actualización
- Etiquetas que distinguen configuración de pruebas individuales
- Versión de Pillow Pair validada con salud e inicio central
- Inicio de autorización verificado sin completar una sesión de usuario
- Proveedor Google configurado; falta la prueba de aceptación con un usuario real