OpenID Notas de implementación de Connect

Editar en línea

IBM® Verify sigue introduciendo mejoras de seguridad en la implementación de « OpenID Connect» siguiendo las mejores prácticas en materia de seguridad. Se mantendrá la compatibilidad con las versiones anteriores en la medida de lo posible, pero deberá modificar algunos elementos para mejorar la seguridad.

Cambios en la implementación de « OpenID Connect»

  • Es posible que algunos mensajes de error se actualicen, pero el ID del mensaje seguirá siendo el mismo. Si tienes algún proceso que incluya lógica para leer mensajes de respuesta, utiliza el ID del mensaje en su lugar.
  • Cuando se accede al punto final de autorización para obtener un código de autorización o tokens, es posible que se redirija al usuario para que inicie sesión o realice una autenticación multifactorial. En un navegador, esta acción provoca algunas redirecciones automáticas. Si tu automatización de pruebas se basa en este flujo, asegúrate de seguir también automáticamente las redirecciones.
  • En el caso de los puntos finales que devuelven un ámbito, no devolver ningún ámbito o devolver una cadena vacía para los ámbitos se trata de la misma manera.
  • Es posible que la barra (/) no aparezca precedida de un carácter de escape en una cadena JSON. Asegúrate de que tu analizador JSON sea compatible con ambos.
  • Los permisos de la API ya no aparecen en la ventana de solicitud de consentimiento del usuario. Los derechos de la API siguen concediéndose a los tokens generados para ese cliente.
  • La especificación permite el uso del http esquema en el redirect_uri solo si el hostname es localhost o los literales de bucle de retorno IP. Consulte OpenID, la sección «Connect Core» 1.0: y la sección 3.1.2.1. Solicitud de autenticación.
  • No siempre se espera que los parámetros de consulta sigan el mismo orden. Al procesar los parámetros de consulta, utiliza la biblioteca adecuada o cuenta con un mecanismo fiable regex que permita localizar el parámetro independientemente del orden.

Cambios futuros en la implementación de « OpenID Connect»

No es necesario que realice ningún cambio inmediato en relación con los siguientes puntos. No obstante, es muy recomendable que modifique estos elementos para garantizar que su implementación de OpenID Connect se ajuste a las mejores prácticas y esté preparada para futuros cambios.
  • Por lo general, es más seguro que las solicitudes POST incluyan los parámetros en el cuerpo de la solicitud en lugar de en los parámetros de consulta.
  • El nonce parámetro debe ser un valor aleatorio desde el punto de vista criptográfico para que los atacantes no puedan adivinarlo. Asegúrate de que sea lo suficientemente larga y aleatoria. Consulte las notas de implementación de Nonce. Se recomienda utilizar un mínimo de 8 caracteres.
  • El servidor de autorización (IBM Verify) genera un código de autorización y tokens que pueden tener cualquier longitud, lo cual podría cambiar en el futuro por motivos de seguridad. Al almacenar los tokens, asegúrate de que la longitud de cada uno sea de al menos 1024 caracteres. La longitud de los tokens en formato JWT, como el token de identificación o el token de acceso en formato JWT, depende del contenido del JWT. El contenido del JWT se amplía a medida que se le asignan más atributos.
  • El tipo de token para los tokens de portador no distingue entre mayúsculas y minúsculas; por ejemplo, «Bearer» o «bearer». No utilices ninguna validación que distinga entre mayúsculas y minúsculas para este valor.
  • Cuando se lleva a cabo el flujo de renovación del token, los nuevos tokens de identificación no contienen el nonce original. El nonce que se devuelve desde el flujo original se utiliza para mitigar los ataques de repetición en las solicitudes de autorización, y esta medida de mitigación no es necesaria para las solicitudes de token posteriores en el flujo de token de actualización.
  • Al igual que nonce, el verificador de código PKCE debe ser un valor aleatorio desde el punto de vista criptográfico e imposible de adivinar. Las especificaciones exigen que el verificador de código tenga una longitud mínima de 43 caracteres. Véase el RFC 7636.
  • Utiliza el state parámetro para evitar la falsificación de solicitudes entre sitios, asignándole un valor imposible de adivinar que pueda validarse. Por ejemplo, genera un hash de la cookie de sesión que se utiliza para autenticar el agente de usuario. Véase el RFC 6749. Se recomienda utilizar un mínimo de 8 caracteres.
  • El valor de aud la audiencia puede ser una cadena o una matriz. En concreto, si solo hay un valor para la audiencia, puede ser una cadena o una matriz que contenga una sola cadena.
  • El tipo de concesión de credenciales de cliente está pensado para generar tokens de acceso para el acceso entre máquinas. No esperes que este tipo de concesión pueda generar un token de identificación ni que el token de acceso sirva para acceder al userinfo punto final.
  • El typ parámetro de encabezado (tipo) del token de identificación es opcional. La parte que confía en el token no debe esperar encontrar un typ parámetro de encabezado en el token de identificación.