La diferencia entre los protocolos SSO SAML y OAuth2
El nombre completo de SAML es Security Assertion Markup Language (Lenguaje de marcado de aserción de seguridad) Es un estándar abierto basado en el formato XML desarrollado por OASIS y se utiliza entre el Proveedor de identidad (IdP) y el Proveedor de servicios (SP). Intercambiar datos de autenticación y autorización.
Una aplicación muy importante de SAML es el inicio de sesión único (SSO) basado en web.
Hay tres roles definidos en el protocolo SAML, a saber, principal: el sujeto representativo generalmente representa a los usuarios humanos. Proveedor de identidad (IdP) Proveedor de identidad y Proveedor de servicios (SP) Proveedor de servicios.
La función del IdP es realizar la autenticación de identidad y transmitir la información de autenticación y la información de autorización del usuario al proveedor de servicios.
La función del SP es verificar la información de autenticación del usuario y autorizar a los usuarios a acceder a información de recursos específica.
A continuación, analicemos cómo funciona SAML a través del diagrama de flujo de autenticación SAML SSO.
En la imagen de arriba, el agente de usuario es el navegador web. Veamos cómo se maneja el protocolo SAML si un usuario quiere solicitar recursos a un proveedor de servicios.
SP realizará los correspondientes controles de seguridad de los recursos. Si se encuentra un contexto de seguridad válido, el SP omitirá los pasos 2 a 7 y procederá directamente al paso 8.
RelayState es un tipo de información de estado mantenida por SP, utilizada principalmente para prevenir ataques CSRF.
Entre ellos, este SAMLRequest está codificado en Base64
Por razones de seguridad, el SAMLRequest también se puede firmar con la clave de firma proporcionada por el SP.
Después de recibir esta solicitud de AuthnRequest, el IdP realizará una verificación de seguridad. Si se trata de una AuthnRequest legal, se mostrará la interfaz de inicio de sesión.
Este formulario contiene información de SAMLResponse y SAMLResponse contiene información relacionada con el usuario.
El mismo SAMLResponse también está codificado en Base64
Podemos ver que samlp:Response contiene información saml:Assertion.
Podemos ver que todo el intercambio de información anterior lo completa el navegador front-end y no hay comunicación directa entre el SP y el IdP.
La ventaja de este método de intercambio de información es que el proceso del protocolo es muy simple y todos los mensajes son simples solicitudes GET o POST.
Si quieres aumentar la seguridad, también puedes utilizar mensajes informativos. En otras palabras, lo que devuelve el IdP no es una aserción SAML directa, sino una referencia a la aserción SAML. Una vez que el SP recibe esta referencia, puede consultar la afirmación SAML real en segundo plano, mejorando así la seguridad.
El protocolo SAML se formuló en 2005 y estaba dirigido básicamente a aplicaciones web. Sin embargo, las aplicaciones web en ese momento eran relativamente simples, y mucho menos el soporte para Apps.
SAML necesita transmitir información del usuario a través de los protocolos HTTP Rect y HTTP POST, generalmente enviando datos en formato de formulario HTML. Por ejemplo, si la aplicación no es una aplicación web, es una aplicación móvil.
El enlace de inicio de esta aplicación móvil es my-photos://authenticate, pero es posible que la aplicación móvil no pueda obtener el contenido del cuerpo del Http POST. Sólo pueden pasar parámetros a través de la URL.
Esto significa que SAML no se puede utilizar en aplicaciones móviles.
Por supuesto, puedes trabajar si quieres, pero necesitas hacer algunos cambios. Por ejemplo, una aplicación de terceros analiza el mensaje POST y luego la SAMLRequest analizada se pasa a la aplicación en forma de parámetros de URL.
Otro método es utilizar OAuth2.
Porque Oauth2 solo se produjo en 2012. Por lo que no existen tantas restricciones de uso. Podemos utilizar OAuth2 en diferentes situaciones.
Echemos un vistazo al diagrama de flujo de autorización en OAuth2:
En términos generales, OAuth2 tiene cuatro roles.
Propietario del recurso: Representa al propietario del recurso y puede autorizarlo proporcionando un nombre de usuario y contraseña u otros métodos. Generalmente viene solo.
Servidor de recursos: Indica el servidor que finalmente necesita acceder a los recursos. Por ejemplo, información de usuario obtenida después de la autorización de github.
Cliente: Un cliente utilizado para interactuar en nombre del propietario del recurso.
Servidor de autorización: un servidor utilizado para la autorización que puede generar los tokens de acceso correspondientes.
Todo el proceso es el siguiente:
El cliente inicia una solicitud de autorización al propietario del recurso, y el propietario del recurso ingresa la información de autenticación correspondiente y devuelve el permiso de autorización al cliente.
Luego, el cliente solicita permiso de autorización al servidor de autorización y devuelve un token de acceso.
Luego, el cliente puede usar este token de acceso para solicitar el servidor de recursos y eventualmente obtener los recursos restringidos.
OAuth2 no especifica cómo interactúa el servidor de recursos con el servidor de autorización. Tampoco se especifica el contenido y el formato de la información del usuario devuelta. Estos deben ser decididos por los propios implementadores.
De forma predeterminada, OAuth2 funciona en un entorno HTTPS, por lo que no existe un método acordado para cifrar la información. Necesitamos hacerlo realidad nosotros mismos.
Finalmente, OAuth2 es un protocolo de autorización, no un protocolo de autenticación. Para este problema, puedes considerar usar el protocolo OpenID Connect. Porque OpenID Connect se basa en OAuth2 y agrega un protocolo de autenticación.
OpenID Connect, abreviado como OIDC, se ha convertido en el estándar universal para el inicio de sesión único y la gestión de identidades en Internet. Construye la capa de identidad en OAuth2, que es un protocolo estándar de autenticación de identidad basado en el protocolo oauth 2.
OAuth2 es en realidad solo autorización. OpenID Connect agrega autenticación además de la autorización.
Las ventajas de OIDC son: token de identidad (JWT) basado en JSON simple y compatibilidad total con el protocolo OAuth2.
En el protocolo SAML, el token SAML ya contiene información de identidad del usuario, pero en OAuth2, después de obtener el token, es necesario verificarlo nuevamente.
Por otro lado, OAuth2 puede invalidar el token en el lado del servidor de autorización porque requiere otra autenticación.
Quienes hayan realizado SSO deberían haber oído hablar de CAS. El nombre completo de CAS es Servicio de autenticación central, que es un marco de autenticación SSO de código abierto a nivel empresarial.
CAS integra los protocolos CAS1, 2, 3, SAML1, 2, OAuth2, OpenID y OpenID Connect, y es muy potente. Presentaremos el uso de CAS en un artículo posterior.