Tokens web de JSON frente a SAML

18

No sé mucho sobre seguridad. Específicamente, no entiendo la diferencia entre JSON Web Tokens, SAML y OAuth 2. Si pudiera proporcionar algunos indicadores y una descripción general de alto nivel de sus funciones, me ayudaría más adelante en la investigación de los detalles.

Específicamente, ¿por qué usaría SAML sobre los tokens web de JSON o viceversa? ¿Necesito tener OAuth 2 para usar JSON Web Tokens / SAML? ¿O se pueden utilizar JSON Web Tokens / SAML de forma independiente?

    
pregunta Jadiel de Armas 26.02.2015 - 15:39
fuente

1 respuesta

19

SAML y OAuth 2 son protocolos utilizados en la autenticación / autorización. JSON Web Tokens (JWT) es una especificación para un token que se puede usar en muchas aplicaciones o protocolos: sucede que el protocolo OpenID Connect (OIDC) utiliza el JWT. SAML también define su propio token: SAML Assertion; al igual que OAuth 2: Access Token. Los tokens utilizados por estos protocolos indican que ha sido autenticado / autorizado y transmite información sobre usted o la sesión.

+----------+----------------+-------------------------------+
| Protocol | Token          | Technologies | Design Pattern |
+==========+================+==============+================+
| SAML     | SAML Assertion | SOAP, XML    | Facade         |
+----------+----------------+--------------+----------------+
| OAuth 2  | Access Token   |              | Proxy          |
+----------+----------------+--------------+----------------+
| OIDC     | Access Token,  | REST, JSON   | Decorator      |
|          | ID Token (JWT) |              |                |
+----------+----------------+--------------+----------------+

Los patrones de diseño de software asociados con cada uno de los protocolos en la tabla anterior resumen en una palabra lo que se pretendió que estos protocolos lograron.

SAML . El patrón de fachada proporciona una interfaz unificada para un conjunto de interfaces en un subsistema. SAML es el sistema de identidad federado original, inventado por las universidades para permitir que los estudiantes accedan a otras bibliotecas universitarias, pero cada universidad mantiene su propio sistema de identidad estudiantil. Estándar de facto en la mayoría de los entornos empresariales. Construido alrededor de XML y SOAP.

OAuth 2 . El proxy, al igual que su nombre indica, permite a los clientes acceder a su información como si fuera un proxy para usted.

OIDC . Extiende OAuth 2 al agregar el ID de usuario y la información del usuario al protocolo. A menudo considerado como una versión moderna de SAML. Uso generalizado en el espacio del consumidor: casi todos los sitios de redes sociales son compatibles con OIDC. Construido alrededor de JSON y REST.

Esperemos que esto desenrede un poco tus preguntas. No puedes comparar SAML (protocolo) con JWT (token), pero puedes comparar SAML con OIDC. Sin embargo, puede comparar una aserción SAML con un JWT OIDC. La especificación OAuth 2 no especifica la estructura subyacente de sus tokens. También puede resultarle interesante que OIDC pueda consumir la afirmación SAML, así como su propio JWT.

El consenso es que OIDC eventualmente reemplazará a SAML, pero SAML ha existido desde 2005 y es muy maduro, un rasgo importante en los entornos empresariales. Aunque OIDC es relativamente nuevo (2014), se espera que las soluciones de autenticación en estos días (2018) lo respalden. SAML se diseñó en una era en la que los navegadores web eran dominantes y tiene un poco de tiempo incómodo con aplicaciones móviles o modernas. OIDC, por otro lado, es compatible con tecnologías modernas como REST y JSON que lo hacen mucho más accesible desde aplicaciones en estos días.

Sin embargo, OAuth 2, OIDC y SAML no especifican realmente cómo se realizan la autenticación y la autorización de la manera en que tradicionalmente se definen esos dos términos.

Cuando escuchas la autenticación, piensas en un nombre de usuario / contraseña, huella digital o código de acceso enviado a tu teléfono: ninguno de estos protocolos cubre estos detalles, sino que la autenticación se delega al proveedor de identidad (IdP). Estos protocolos especifican cómo debe ser redirigido a un IdP para autenticarse y, si tiene éxito, cómo se devuelven los tokens / aserciones.

La "autorización" de

OAuth 2 se relaciona con la obtención del consentimiento del usuario , es decir, si se le otorga a un servicio acceso a su información / datos, no significa autorización en el control de acceso sentido. OIDC al igual que OAuth 2 también es compatible con los medios para obtener el consentimiento del usuario. Si bien SAML también admite el consentimiento del usuario, generalmente no se usa en un entorno de empresa / intranet.

La autorización (que se refiere al significado de control de acceso más tradicional) tampoco se encuentra en las especificaciones OAuth 2, OIDC y SAML, pero permite que los tokens contengan notificaciones, por ejemplo, si un usuario pertenece a un grupo de administradores, que los servicios del cliente pueden interpretar. sin embargo le gusta.

OAuth 2, OIDC y SAML son excelentes facilitadores para diferentes esquemas de autenticación y autorización (control de acceso), pero en realidad no especifican los mecanismos subyacentes reales.

ACTUALIZACIÓN 9/5/2018. Actualizado para 2018.

ACTUALIZACIÓN 26/04/2017. Se corrigió una afirmación incorrecta acerca de que SAML no es compatible con el consentimiento del usuario, pero no se usa ampliamente.

ACTUALIZACIÓN 2/22/2017. Aclare la autenticación, la autorización (control de acceso) y el consentimiento del usuario en respuesta al comentario del usuario a continuación.

    
respondido por el HTLee 29.06.2016 - 03:30
fuente

Lea otras preguntas en las etiquetas