OpenID Notas de aplicación de Connect

Editar en línea

IBM® Verify sigue introduciendo mejoras de seguridad en la aplicación de OpenID Connect siguiendo las mejores prácticas de seguridad. La compatibilidad con las versiones anteriores se va a mantener en la medida de lo posible, pero hay que cambiar algunos elementos para mejorar la seguridad.

Cambios para la implantación de OpenID Connect

  • Algunos mensajes de error pueden actualizarse, pero el ID del mensaje sigue siendo el mismo. Si tiene algún proceso con lógica que lea mensajes de respuesta, utilice en su lugar el ID del mensaje.
  • Cuando el punto final de autorización es golpeado para obtener un código de autorización o tokens, podría redirigir al usuario para el inicio de sesión o autenticación multifactor. En un navegador, esta acción da lugar a algunas redirecciones automáticas. Si su automatización de pruebas se construye alrededor de este flujo, asegúrese también de seguir automáticamente las redirecciones.
  • Para los endpoints que devuelven un ámbito, no devolver ámbitos o devolver una cadena vacía para los ámbitos se tratan igual.
  • Una barra oblicua (/) en una cadena JSON podría no ser escapada. Asegúrese de que su analizador JSON es compatible con ambos.
  • Los derechos de API ya no aparecen en la solicitud de consentimiento del usuario. Los derechos de la API se siguen concediendo a los tokens generados para ese cliente.
  • La especificación permite el uso del esquema http en el redirect_uri sólo si el hostname es localhost o los literales IP loopback. Consulte la sección OpenID 1.0: Conectar 3.1.2.1 núcleo. Solicitud de autenticación.
  • No siempre se espera que los parámetros de consulta estén en el mismo orden. Al procesar parámetros de consulta, utilice la biblioteca adecuada o disponga de un regex robusto que pueda encontrar el parámetro independientemente del orden.

Futuros cambios para la implantación de OpenID Connect

No es necesario realizar cambios inmediatos en los siguientes puntos. Sin embargo, se recomienda encarecidamente cambiar estos elementos para garantizar que la implementación de OpenID Connect sigue las mejores prácticas y está preparada para futuros cambios.
  • Generalmente, es más seguro para las peticiones POST tener los parámetros en el cuerpo de la petición en lugar de los parámetros de consulta.
  • El parámetro nonce debe ser un valor criptográficamente aleatorio para que no pueda ser adivinado por los atacantes. Asegúrese de que es suficientemente largo y aleatorio. Véase Notas sobre la implementación de Nonce. Se recomienda un mínimo de 8 caracteres.
  • El servidor de autorización (IBM Verify) genera un código de autorización y tokens que pueden ser de cualquier longitud, que podría cambiar en el futuro por razones de seguridad. Cuando se almacenen los tokens, permita al menos 1024 caracteres para la longitud del token. 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 cuando se le asignan más atributos.
  • El tipo de ficha para las fichas de portador no distingue entre mayúsculas y minúsculas, por ejemplo "Portador" o "portador". No utilice ninguna validación que distinga entre mayúsculas y minúsculas para este valor.
  • Cuando se realiza el flujo de actualización de tokens, los nuevos tokens de identificación no tienen el nonce original. El nonce que se devuelve desde el flujo original se utiliza para mitigar los ataques de repetición en la solicitud de autorización y esta mitigación no es necesaria para las solicitudes de token posteriores para el flujo de actualización de token.
  • Al igual que en nonce, el verificador del código PKCE debe ser un valor criptográficamente aleatorio e indescifrable. El pliego de condiciones exige que el código verificador tenga al menos 43 caracteres. Véase RFC 7636.
  • Utilice el parámetro state para evitar la falsificación de solicitudes en sitios cruzados convirtiéndolo en un valor indescifrable que pueda validarse. Por ejemplo, generar un hash de la cookie de sesión que se utiliza para autenticar el agente de usuario. Véase RFC 6749. Se recomienda un mínimo de 8 caracteres.
  • El valor de audiencia de aud puede ser una cadena o una matriz. En particular, si sólo existe un valor para el público, puede ser una cadena o una matriz con una cadena.
  • El tipo de concesión cliente-credencial está pensado para generar tokens de acceso para el acceso máquina a máquina. No espere que este tipo de concesión pueda generar un token de identificación o utilizar el token de acceso para acceder al endpoint userinfo .
  • El parámetro de encabezado typ (tipo) en el token ID es opcional. La parte que confía no debe esperar un parámetro de encabezado typ en el token de identificación.