Gestión de la identidad: SAML vs. OAuth2 vs. OpenID Connect
Todo comenzó con las organizaciones que necesitaban una forma de centralizar sus sistemas de autenticación para una mejor gestión y seguridad. Ahí es donde apareció el Single Sign On (SSO). El inicio de sesión único (SSO) es un servicio centralizado de autenticación de sesiones y usuarios en el que se puede utilizar un conjunto de credenciales de inicio de sesión para acceder a varias aplicaciones. Su belleza está en su simplicidad; el servicio te autentifica en una plataforma, permitiéndote iniciar sesión de forma transparente en varios servicios internos sin tener que entrar y salir cada vez.
Luego vinieron los desarrolladores de aplicaciones de terceros que querían utilizar las API internas para integrarlo con sus productos y soluciones, esto era claramente un desafío. Luego llegaron las redes sociales y complicaron aún más las cosas, actualmente tenemos miles de apps que soportan la autenticación a través de redes sociales como Facebook, Google, Twitter, LinkedIn, etc. El problema en estas arquitecturas es el reto de mantener las cosas lo más simple posible y aumentar la seguridad al mismo tiempo. ¿La solución? Identidades federadas.
Actualmente, los tres principales protocolos de identidad federada son: SAML, OAuth2 & OpenID Connect. Antes de profundizar en estos tres protocolos, vamos a discutir algunos conceptos comunes que la gente tiende a confundir.
Cuando se trata de la seguridad y el acceso, la autenticación & la autorización son dos términos que la gente tiende a pasar por alto y que a menudo se confunden para significar lo mismo. Pues bien, la autenticación es la verificación de tu identidad mientras que la autorización es la verificación de a qué tienes acceso.
La autenticación es la validación de las credenciales de inicio de sesión antes de dar al usuario acceso al sistema. Cuando se trata de seguridad, se recomienda utilizar al menos dos factores de autenticación antes de conceder al usuario el acceso a cualquier cosa. (2FA, MFA, tokens digitales & físicos, etc.).
La autorización se produce después del proceso de autenticación verificando tus derechos antes de concederte el acceso a los recursos necesarios como bases de datos, archivos, repositorios, etc. Un ejemplo práctico sería una vez verificados los inicios de sesión de un empleado, es ver a qué pisos tiene acceso.
Tanto la autorización & como la autenticación son cruciales para la seguridad y la gestión de accesos y aunque ambas tienen conceptos diferentes detrás, son un elemento crítico para la infraestructura de un sistema y entenderlas es clave para la gestión de identidades y accesos.
SAML
Security Assertion Markup Language (SAML) es un estándar abierto basado en XML que se utiliza para las implementaciones de single sign on (SSO). SAML 2.0 se publicó en 2005 y es la versión actual del estándar.
SAML se utiliza tanto para la autenticación & como para la autorización entre dos partes: un proveedor de servicios (Office365, Salesforce, G Suite, etc.) & un proveedor de identidades (Okta, OneLogin, Ping Identity, etc.). El proveedor de servicios (SP) acepta confiar en el proveedor de identidad (IdP) en el proceso de autenticación. Esto se hace a través de un documento SAML XML enviado por el IdP que contiene la autorización del usuario & de autenticación y luego se redirige al proveedor de servicios.
Consideremos este ejemplo:
- Proveedor de identidad (IdP): Okta
- Proveedor de servicios (SP): Aplicación Salesforce
- El usuario intenta iniciar sesión en la aplicación Salesforce de su empresa desde Chrome.
- La aplicación Salesforce responde generando una solicitud SAML
- Chrome redirige al usuario a una URL SSO, Okta analiza la solicitud SAML, autentifica al usuario (esto podría ser a través de nombre de usuario y contraseña, autenticación de dos factores o MFA es el usuario no está en la red interna de la empresa; si el usuario ya está autenticado en Okta, este paso se omitirá) y genera una respuesta SAML.
- Okta reenvía la respuesta SAML codificada a Chrome
- Chrome redirige la respuesta SAML a la aplicación de Salesforce
- Si la verificación es satisfactoria, el usuario iniciará sesión en la aplicación de Salesforce y se le concederá acceso a todos los distintos recursos.
- Propietario del recurso: Generalmente el propio usuario
- Cliente: Aplicación que solicita acceso a un servidor de recursos
- Servidor de recursos: Servidor que aloja datos protegidos (por ejemplo, Facebook que aloja su perfil e información personal)
- Servidor de autorización: Servidor que emite el token de acceso al cliente. Este token se utilizará para que el cliente solicite el servidor de recursos.
OAuth2
«¿Cómo puedo permitir que una aplicación acceda a mis datos sin tener que darle necesariamente mi contraseña?»
OAuth2 es un estándar abierto utilizado para la autorización, que permite a las aplicaciones proporcionar una «autorización delegada». A diferencia de otros frameworks que proporcionan autenticación, OAuth sólo autoriza dispositivos, API, servidores con tokens de acceso en lugar de credenciales y funciona sobre HTTPS.
Si alguna vez has visto uno de los diálogos de abajo, es de lo que estamos hablando. Se trata de una aplicación preguntando si puede acceder a los datos en su nombre. Esto es OAuth.
Puedes pensar en esto como las tarjetas de las llaves del hotel, pero para las aplicaciones. Si tienes una tarjeta llave de hotel, puedes acceder a tu habitación. ¿Cómo se consigue una tarjeta llave de hotel? Tienes que hacer un proceso de autentificación en la recepción para conseguirla. Después de autenticarse y obtener la tarjeta llave, puedes acceder a los recursos de todo el hotel.
OAuth define cuatro roles:
A continuación se muestra un diagrama del flujo de OAuth2.
Consideremos este ejemplo:
- Spotify quiere acceder a tu lista de amigos desde tu cuenta de facebook.
- Spotify te redirige al servidor de autorización (facebook en este caso)
- Si autorizas el acceso, el servidor de autorización envía un código de autorización al cliente (Spotify) en la respuesta de callback.
- Entonces, este código se intercambia contra un token de acceso entre el Facebook y Spotify.
- Ahora Spotify es capaz de utilizar este token de acceso para consultar al servidor de recursos (Facebook) y recuperar tu lista de amigos.
Una cosa a tener en cuenta es que el usuario nunca llega a ver el token de acceso, se almacenará en la sesión. El servidor de autorización también envía otra información como el tiempo de vida del token y un token de refresco.
OpenID Connect
OpenID Connect es una simple capa de identidad sobre el protocolo OAuth 2.0 que extiende OAuth2 y permite la ‘autenticación federada’.
El flujo del proceso de OpenID Connect es similar al flujo de autorización de OAuth2 con la principal diferencia de un ‘id-token’ que permite la autenticación del usuario.
Nótese que la Autenticación Federada es completamente diferente a la Autorización Delegada. Tomemos de nuevo el ejemplo de Facebook y Spotify
- Autenticación Federada es iniciar sesión en Spotify usando tus credenciales de Facebook.
- Autorización Delegada es la capacidad de una aplicación externa para acceder a los recursos. En este caso, Spotify intenta acceder a tu lista de amigos de Facebook para importarla a Spotify.
Para terminar, aquí tienes una tabla que resume los tres protocolos/marcos.