Comprender la diferencia entre autenticación y autorización es fundamental para diseñar soluciones seguras en la nube. Ambos conceptos trabajan en conjunto dentro de Azure Active Directory, pero cumplen roles muy distintos que determinan cómo se verifica la identidad de un usuario y qué acciones puede realizar dentro de un sistema.
¿Qué diferencia existe entre autenticación y autorización?
La autenticación consiste en demostrar que eres quien dices ser [0:03]. Cuando un usuario presenta sus credenciales ante Azure Active Directory, el servicio valida que sean correctas. Pero el proceso no termina ahí: adicionalmente se analizan señales que permiten identificar si el usuario se encuentra en riesgo o si se trata de un inicio de sesión sospechoso.
Microsoft utiliza el protocolo OpenID Connect para administrar la autenticación [0:26].
Por otro lado, la autorización es el paso que determina qué puede hacer una identidad ya verificada [0:41]. Estar autenticado no significa tener permiso para realizar cualquier acción. Aquí entra un principio clave: conceder los permisos mínimos requeridos para llevar a cabo una actividad. Esto permite disminuir la superficie de ataque.
Un ejemplo claro: una aplicación a la que le otorgas permiso para acceder a tus contactos podría leerlos, pero no tendría la opción de crear nuevos ni eliminarlos [0:54]. Para la autorización, Microsoft emplea la plataforma de identidad OAuth 2.0 [1:10].
¿Qué escenarios se habilitan al combinar autenticación y autorización?
Al delegar ambas actividades a Azure Active Directory, se abren varios escenarios de seguridad avanzada [1:17]:
- Directivas de acceso condicional: permiten definir reglas que controlan el acceso según condiciones específicas.
- Autenticación multifactor (multifactor authentication): cuando se detecta una señal de riesgo, se solicita al usuario que verifique su identidad mediante un segundo factor [1:30].
- Inicio de sesión único (single sign-on): una vez que el usuario inicia sesión con su identidad, otras aplicaciones que utilizan esas mismas credenciales pueden llamar a diferentes servicios sin requerir que el usuario vuelva a autenticarse [1:44].
El inicio de sesión único mejora significativamente la experiencia de usuario, ya que evita que cada vez que una aplicación necesite llamar a APIs distintas o se utilicen múltiples aplicaciones, el usuario tenga que escribir sus credenciales nuevamente [2:01].
¿Qué protocolo usar según el tipo de aplicación?
La elección del protocolo depende directamente de la arquitectura de tu solución [2:14]:
¿Tu aplicación es completamente en la nube?
- Utiliza OpenID Connect para la autenticación.
- Utiliza OAuth 2.0 para la autorización.
¿Tu aplicación se integra con servicios on premises?
Cuando existe integración con un Active Directory local, el esquema cambia [2:27]:
- Utiliza SAML para la autenticación.
- Utiliza OAuth 2.0 para la autorización.
¿Necesitas validación de identidad por un tercero?
Existe un escenario donde la identidad del usuario debe ser verificada por una entidad externa. En este caso se emplea Azure Active Directory B2C [2:38]. El flujo funciona así:
- El usuario envía información inicial, incluyendo documentos que prueben su identidad.
- Un tercero valida esos documentos y genera un puntaje de riesgo digital [2:50].
- Los documentos se verifican y solo entonces se concede el acceso.
Este tipo de verificación resulta útil en escenarios donde se necesita certeza absoluta sobre la identidad, como al otorgar un crédito, evitando así la suplantación de identidad [3:03].
Cada escenario de seguridad tiene su protocolo adecuado. OpenID Connect resuelve la autenticación, OAuth 2.0 gestiona la autorización, y SAML entra en juego cuando hay infraestructura local involucrada. Si estás diseñando una solución en Azure, ¿qué combinación de protocolos se ajusta mejor a tu arquitectura? Comparte tu caso en los comentarios.
