Seguridad
¿Acepta su aplicación lo que debería rechazar? ID-Kit hace de IdP y envía respuestas trampa: usted comprueba que cada trampa se rechaza.
Su aplicación debe rechazar o leer solo la aserción firmada. Si inicia sesión como «admin@evil.example», es vulnerable.
Su aplicación debe leer el NameID COMPLETO (alice@example.test.evil.example) o rechazar. Si entiende «alice@example.test», es vulnerable al ataque 2018: un atacante podría suplantar a otra persona.
Su aplicación debe rechazar: nada prueba que la respuesta proceda del IdP.
Su aplicación debe rechazar: la identidad se modificó después de la firma.
Su aplicación debe rechazar: la firma no es del certificado de confianza.
Su aplicación debe rechazar: el ID de una aserción debe ser único; de lo contrario, la firma puede ser secuestrada.
Su aplicación debe rechazar: todas las AudienceRestrictions deben cumplirse (es un Y lógico).
Su aplicación debe mostrar estos valores sin ejecutarlos: ningún script, ningún HTML interpretado, ningún fallo con comillas o emojis.
Su aplicación debe rechazar un segundo envío de la misma aserción (repetición). Pruebe a enviar dos veces la misma respuesta.
Para un inicio de sesión iniciado por su aplicación, debe rechazar una respuesta que no responde a ninguna solicitud (salvo que acepte inicios de sesión iniciados por el IdP).
Su aplicación debe rechazar: el periodo de validez ya ha terminado.
Su aplicación debe rechazar: el periodo de validez no ha comenzado (útil para probar la tolerancia de reloj).
Una aplicación con una tolerancia de reloj de 2 min rechaza; con 5 min o más, acepta. Permite conocer su tolerancia.
La aserción caducó hace 5 minutos: se rechaza si la tolerancia es inferior a 5 min.
Su aplicación debe considerar terminada la sesión del IdP: no debe abrir una sesión más larga que esta.
Su aplicación debe rechazar: la aserción está destinada a otra aplicación.
Su aplicación estricta debe rechazar: nada indica a qué aplicación va dirigida la aserción.
Su aplicación debe rechazar: la confirmación nombra otra dirección ACS.
Su aplicación debe rechazar: la respuesta está dirigida a otra URL.
Su aplicación debe rechazar: esta respuesta no corresponde a ninguna de sus solicitudes.
Su aplicación debe rechazar: la respuesta afirma proceder de un IdP distinto del que configuró.
Su aplicación debe rechazar o mostrar un error claro: no sabe quién inicia sesión.
El inicio de sesión puede funcionar, pero la aplicación debe gestionar la falta de nombre, correo o grupos sin bloquearse ni conceder derechos por defecto.
Si su aplicación pidió autenticación fuerte (RequestedAuthnContext), debe rechazar: el IdP solo declara una simple contraseña.
Si la aplicación tiene AMBOS certificados (antiguo + nuevo, opción «publicar el siguiente certificado»), acepta; si solo conservó el antiguo, rechaza. Revela si una rotación de certificado provocará una interrupción.
Su aplicación debe rechazar: no puede descifrar la aserción y debe decirlo claramente (sin fallar).
Su aplicación debe mostrar un error claro y no iniciar sesión a nadie.
Su aplicación, si pidió IsPassive, debe redirigir a una pantalla de inicio de sesión normal en lugar de mostrar un error bruto.
Su aplicación debe mostrar un error claro (el IdP se niega a procesar la solicitud), sin fallar ni entrar en bucle.
Su aplicación debe indicar que su solicitud (formato de NameID) no es aceptada por el IdP.
Su aplicación debe mostrar un error de protocolo limpio, sin fallar.
No envíe nunca secretos reales: son identidades ficticias.