Comprender la diferencia entre autenticación y autorización es fundamental para diseñar soluciones seguras en la nube. Azure Active Directory actúa como el centro de estas operaciones, validando identidades y controlando el acceso a recursos según el principio de mínimos privilegios. A continuación se desglosan los conceptos, protocolos y escenarios más relevantes.
¿Qué diferencia existe entre autenticación y autorización?
La autenticación consiste en demostrar que eres quien dices ser [0:03]. Cuando presentas tus credenciales a Azure Active Directory, el servicio valida que sean correctas. Además, se evalúan diferentes señales para determinar si el usuario se encuentra en riesgo o si se trata de un inicio de sesión sospechoso.
Microsoft emplea el protocolo OpenID Connect para administrar este proceso de verificación de identidad [0:27].
Por otro lado, la autorización se encarga de conceder a la parte ya autenticada el permiso para realizar acciones específicas [0:44]. Aquí se define qué datos se pueden acceder y qué operaciones están permitidas. Un ejemplo claro: una aplicación a la que le otorgues permiso para ver tus contactos podría leerlos, pero no crear nuevos ni eliminar los existentes [0:56]. Para la autorización, Microsoft utiliza la plataforma de identidad OAuth 2.0 [1:10].
El concepto de principio de mínimos privilegios es clave: solo se conceden los permisos estrictamente necesarios para llevar a cabo una actividad, lo que reduce la superficie de ataque [0:35].
¿Qué escenarios se habilitan al combinar autenticación y autorización?
Al delegar ambas funciones a Azure Active Directory se abren posibilidades como:
- Directivas de acceso condicional: reglas que determinan si se permite o bloquea un inicio de sesión según contexto y riesgo [1:20].
- Autenticación multifactor (MFA): cuando se detecta una señal de riesgo, se solicita al usuario que verifique su identidad con un paso adicional [1:28].
- Single sign-on (inicio de sesión único): una vez que el usuario se autentica, otras aplicaciones que comparten esas credenciales pueden invocar distintos servicios sin pedir nuevamente las credenciales [1:40].
El single sign-on mejora significativamente la experiencia de usuario al evitar que se repita el proceso de inicio de sesión cada vez que una aplicación necesita llamar a APIs diferentes o cuando se trabaja con múltiples aplicaciones [1:55].
¿Qué protocolo elegir según el entorno?
La elección del protocolo depende de dónde residen los servicios:
- Solo servicios en la nube: usa OpenID Connect para autenticación y OAuth 2.0 para autorización [2:08].
- Integración con servicios on-premises: emplea SAML para autenticación y OAuth 2.0 para autorización [2:18]. Este escenario aplica cuando la aplicación necesita conectarse con un Active Directory local.
¿Cómo funciona la verificación de identidad por terceros?
Cuando se requiere que la identidad del usuario sea validada por un tercero, se utiliza Azure Active Directory B2C [2:30]. El flujo es el siguiente:
- El usuario envía información inicial, incluyendo documentos que prueben su identidad.
- Un tercero verifica los documentos y calcula un puntaje de riesgo digital [2:42].
- Con esa validación se confirma que el usuario es quien dice ser y se concede el acceso.
Este tipo de verificación es útil en escenarios donde se necesita alta certeza sobre la identidad, como la aprobación de un crédito o la prevención de suplantación de identidad [2:55].
Si trabajas con Azure Active Directory, recuerda siempre asociar cada capa de seguridad con su protocolo correspondiente: OpenID Connect para saber quién eres y OAuth 2.0 para definir qué puedes hacer. ¿Has implementado alguno de estos protocolos en tus proyectos? Comparte tu experiencia en los comentarios.
