¿Cómo se comparan los formatos de token STS entre sí SAML vs SWT vs JWT?

Mejor o peor es relativo al uso del protocolo. SAML tiene su lugar y SWT / JWT / et tiene su lugar. La especificación SAML está muy bien establecida, mientras que SWT / JWT están realmente en su infancia y siguen cambiando.

SAML tiene muchas perillas que lo hacen bastante complejo y es el enemigo de la buena seguridad, pero todo el mundo lo implementa de la misma manera. El diseño de SWT / JWT es bastante simple, pero nadie puede estar de acuerdo con un solo estándar de implementación sangrienta y muchas de las bibliotecas públicas utilizadas no se someten a una revisión de seguridad.

También depende de cómo se firman los tokens y cómo se protegen las claves utilizadas para firmar. Los secretos compartidos tienden a ser más difíciles de proteger y PKI es un PITA, pero otros pueden estar en desacuerdo.

Desde el punto de vista de la seguridad, no hay mucha diferencia entre las especificaciones de token JWT y SAML; principalmente se reduce a algoritmos de firma y encriptación compatibles (JWT es más limitado a este respecto; consulte enlace ).

Para este caso de uso, al final, ambos simplemente presentan reclamos (con todo el equipaje necesario, como el tiempo de caducidad, la audiencia, etc.). SIN EMBARGO, el sitio vinculado dice que la implementación de JWTs de ACS no admite el cifrado y, por lo tanto, puede ser "menos" segura. Esto, por supuesto, depende de su caso de uso real.

Lo mismo es cierto para los tokens SWT, que no admiten el cifrado en absoluto. Pero esto podría no ser un problema, ya que los tokens se pueden transmitir a través de un canal seguro que proporciona confidencialidad (por ejemplo, HTTPS).

Y desde un punto de vista no relacionado con la seguridad, tenga en cuenta que puede haber una diferencia de rendimiento que no sea negligente (generalmente, SAML pone la mayor presión en sus recursos).

Al final del día no creo que realmente importe, ya que es una preferencia de formato. SAML 2.0 está escrito en piedra pero es muy grande y detallado (como suele ser XML). Pero en mi preferencia personal estos días con mis propios proyectos. Digo que pruebes tokens JWT , que es un token en formato JSON. Si las aplicaciones de su cliente abarcan diferentes plataformas, podría ser mucho más fácil ver y manejar un objeto JSON.

Mis aplicaciones cliente son

• Aplicación Pure AngularJS
• aplicación para iPhone y iPad iOS
• aplicación de Windows 8
• aplicación de Android

Y está protegido por una API web que acepta tokens de encabezado de autorización con todas las cargas en formato JSON, por lo que JWT me pareció una opción lógica para mí . Cuando esté completamente en .NET, para la facilidad de todo, simplemente use un token SAML.

Cuando está totalmente extendido fuera del puro Microsoft World: recomiendo usar JSON como formato sobre cualquier otro disponible. JSON es el formato de la web moderna en estos días, por lo que también está prácticamente garantizado.

Me doy cuenta de que esta es una pregunta antigua y no soy un experto en seguridad de ninguna manera. Sin embargo, mi experiencia con Azure ACS y los tipos de token me llevó a tres conclusiones:

1. SAML trabajó más o menos fuera de la caja. JWT era mucho más delicado y tuve que confiar en los blogs para que funcionara.
2. El tamaño de las cookies fue equivalente entre SAML y JWT. Mi aplicación de demostración pasó ~ 30 reclamaciones; No vi nada que justificara la afirmación de que JWT es mucho más ligero que SAML.
3. El complemento Visual Studio de Identity and Access proporcionó un medio para configurar un STS local que podría potencialmente utilizarse para simular tokens en el desarrollo. JWT no era una opción en esta herramienta.

Así que fui con SAML.