La autenticación y la autorización son conceptos fundamentales en la gestión de identidades y accesos (IAM), y suelen confundirse entre sí. Aunque ambos están relacionados con la seguridad de la identidad, no son intercambiables.

• La autenticación verifica quién es un usuario.
• La autorización determina lo que el usuario puede hacer.

Por ejemplo, usted inicia sesión en GitHub (autenticación) y, luego, intenta eliminar el repositorio de otra persona. GitHub sabe quién es usted, pero lo detiene (autorización).

La autenticación debe ocurrir primero: usted debe demostrar su identidad. La autorización ocurre después: sus permisos determinan a qué puede acceder.

La autenticación responde la pregunta “¿Quién es?”

Antes de que su aplicación le permita a alguien acceder, debe verificar su identidad. Cuando los usuarios inician sesión, se validan sus credenciales (u otro factor) para confirmar que son quienes dicen ser. La autenticación siempre viene primero. No es posible decidir a qué puede acceder alguien sin antes saber quién es.

Piense en la autenticación como el control de seguridad del aeropuerto. Hay que mostrar una identificación para verificar la identidad, y el personal del aeropuerto verifica que usted sea la persona de la identificación.

• Autenticación basada en contraseña: El usuario proporciona credenciales que se validan con registros almacenados. Las contraseñas por sí solas son cada vez menos seguras para las exigencias modernas.
• Claves de acceso: Los usuarios se autentican con claves criptográficas protegidas localmente mediante códigos PIN de biometría o del dispositivo. Las claves de acceso son credenciales FIDO resistentes al phishing que ofrecen un proceso de inicio de sesión más rápido, fácil y seguro que las contraseñas tradicionales.
• Inicios de sesión sociales e identidad federada: Los usuarios se autentican a través de proveedores externos y de confianza (como Google o GitHub) mediante OpenID Connect (OIDC). Esto delega la verificación de identidad a proveedores de identidades (IdP) especializados.
• Inicio de sesión único (SSO): Los usuarios se autentican una vez para acceder a varias aplicaciones sin tener que volver a ingresar sus credenciales. Esto mejora la experiencia de usuario, especialmente en entornos empresariales.
• Autenticación multifactor (MFA): Combina múltiples factores de verificación (p. ej., de conocimiento, posesión e inherencia) para reforzar la seguridad.

Cuando un usuario solicita acceso a una aplicación:

1. El usuario envía las credenciales al extremo de autenticación
2. El sistema valida las credenciales, ya sea a nivel local o con un IdP
3. Tras la validación exitosa, el sistema emite tokens que representan la identidad autenticada

La autorización responde la pregunta “¿Qué puede hacer?”.

La autorización determina qué pueden hacer los usuarios autenticados dentro de un sistema. Estos son algunos de los enfoques más comunes:

Método	Descripción	Ejemplo
Control de acceso basado en roles (RBAC)	A los usuarios se les asignan roles predefinidos (administrador, editor, lector) con permisos fijos	Un editor puede modificar documentos, mientras que un lector solo puede leerlos
Control de acceso basado en atributos (ABAC)	Decisiones de acceso basadas en atributos dinámicos (propiedades del usuario, metadatos de recursos, contexto del entorno)	Solo es posible acceder a los recursos financieros desde la red corporativa durante el horario laboral
Control de acceso basado en relaciones (ReBAC)	Autorización basada en las relaciones entre usuarios y recursos	Un empleado puede editar sus propios documentos, pero no los borradores privados de sus colegas

La autorización en la práctica

Piense en una aplicación de gestión de proyectos:

• La autenticación confirma que el usuario es Alex.
• La autorización determina que Alex (en el rol de gerente de proyectos) puede ver todos los proyectos del equipo de desarrollo, pero no puede eliminar proyectos ni acceder a la configuración de facturación.

Al trabajar con protocolos modernos, es fundamental comprender las diferencias entre AuthN y AuthZ.

Aspecto	Autenticación (AuthN)	Autorización (AuthZ)
Pregunta	¿Quién es?	¿Qué puede hacer?
Proceso	Verifica la identidad	Verifica los permisos
Secuencia	Debe ocurrir primero	Ocurre después de la autenticación
Métodos	Contraseñas, claves de acceso, MFA, SSO, OIDC	RBAC, ABAC, ReBAC
Tipo de token	Token de identificación (atributos de identidad)	Token de acceso (permisos/ámbitos)
Estado de HTTP	401 - No autorizado (no se pudo demostrar la identidad)	403 - Prohibido (identidad conocida, permiso denegado)

OAuth 2.0 es un marco de autorización. No es un protocolo de autenticación.

OAuth 2.0 proporciona una forma estandarizada de que una aplicación cliente obtenga un token de acceso de un servidor de autorización (con el consentimiento del usuario) para acceder a recursos protegidos. Fue diseñado para la autorización delegada, lo que permite al usuario conceder a una aplicación de terceros acceso limitado a sus recursos sin compartir sus contraseñas.

Presentamos OpenID Connect (OIDC)

OIDC es un protocolo de autenticación con interoperabilidad basado en el marco de trabajo OAuth 2.0. Simplifica el proceso para verificar la identidad del usuario a partir de la autenticación realizada por el servidor de autorización.

Se ocupa de aquello que OAuth 2.0 no cubre:

• Define el token de identificación, es decir, un token de seguridad estandarizado (codificado como JWT) que sirve como prueba de que el usuario se autenticó
• Estandariza los atributos de identidad del usuario (como el nombre y el correo electrónico)

En las arquitecturas modernas:

• OAuth 2.0 gestiona la autorización (delegación de acceso a recursos)
• OpenID Connect gestiona la autenticación (confirmación de la identidad del usuario)

Ambos protocolos suelen funcionar juntos en el mismo flujo.

Las aplicaciones modernas son sistemas distribuidos diseñados en torno a API y se han convertido en uno de los principales medios para acceder a los recursos.

El cambio fundamental es que las API no autentican directamente al usuario, sino que validan el token e implementan la autorización de la API.

Cómo funciona la autenticación basada en tokens

1. El usuario se autentica con un servidor de autorización (proveedor de identidades).
2. El servidor emite tokens tras validar la identidad:
   • Token de identificación (autenticación) con información de identidad del usuario. El cliente lo usa para determinar quién inició sesión.
   • Token de acceso (autorización) con información de autorización (ámbitos, permisos). La API lo usa para determinar a qué puede acceder el usuario.
3. El cliente realiza llamadas a la API con el token de acceso en el encabezado [Authorization: Bearer].
4. La API valida el token e implementa las reglas de autorización basadas en los atributos que contiene.

¿Qué es la autenticación con JWT?

Los tokens web JSON (JWT) son el formato de token más común. Son autónomos, lo cual significa que contienen toda la información necesaria dentro del propio token.

Un JWT está compuesto por un encabezado, una carga útil (atributos) y una firma.

Validación de JWT: ¿qué debe verificar la API?

Cuando una API recibe un JWT, la validación no es negociable. Omitir cualquiera de estas validaciones crea vulnerabilidades de seguridad en las aplicaciones.

Cinco comprobaciones de validación esenciales:

1. Estructura del token: Primero, compruebe que el token coincida con la estructura de un token web JSON.
2. Integridad del token: Compruebe la firma del token para confirmar que no lo hayan manipulado.
3. Vencimiento del token: Compruebe si el token caducó según lo definido en el atributo exp.
4. Autoridad esperada: Confirme que el remitente previsto sea quien emitió y firmó el token.
   1. Compárelo con el atributo iss (emisor).
   2. Compruebe que la clave usada para firmar el JWT pertenezca a la autoridad esperada.
5. Público esperado: Confirme que el token esté destinado a su aplicación y que el atributo aud coincida con el valor que identifique a su aplicación.

JWT vs. tokens opacos: ventajas y desventajas

OAuth 2.0 no exige un formato específico de token de acceso. Aunque los JWT son muy usados, una alternativa es el token opaco, una cadena aleatoria que no contiene información insertada sobre el usuario ni sobre el token en sí.

Artículo destacado	Tokens de acceso JWT	Tokens de acceso opacos
Validación	Sin estado (la API se valida localmente)	Con estado (la API debe llamar al extremo de introspección del servidor de autorización en cada solicitud)
Revocación	Difícil de revocar antes del vencimiento	Capacidad de revocación inmediata
Desempeño	Menor latencia en las solicitudes de API (más rápido)	La búsqueda del servidor de autorización agrega latencia
Escalabilidad	Escalabilidad adecuada en arquitecturas distribuidas	El servidor de autorización se convierte en una dependencia crítica

Ambos son válidos para las implementaciones de OAuth 2.0. Muchos sistemas usan JWT con períodos de vencimiento cortos y rotación de tokens de actualización para equilibrar rendimiento y seguridad.

El flujo de código de autorización con Proof Key for Code Exchange (PKCE) es el flujo de OAuth 2.0 más seguro para aplicaciones web y móviles, lo que demuestra cómo funcionan juntos AuthN y AuthZ. El uso de PKCE protege el flujo de ataques de intercepción.

1. El usuario inicia sesión. La aplicación redirige al usuario al servidor de autorización con los detalles de la solicitud (ID de cliente, ámbitos, desafío de código de PKCE).
2. El usuario se autentica. El usuario inicia sesión mediante la página de inicio de sesión alojada y se completa el proceso de autenticación.
3. Se emite un código de autorización. Se redirige al usuario de vuelta a la aplicación con un código de autorización de corta duración.
4. Se intercambian los tokens. El backend de la aplicación intercambia el código de autorización por tokens y envía el verificador de código de PKCE. El servidor emite el token de identificación (AuthN) y el token de acceso (AuthZ).
5. Se accede a las API. La aplicación incluye el token de acceso en los encabezados de solicitudes cuando llama a API protegidas.
6. Se validan e implementan los tokens. La API valida el token de acceso e implementa permisos en función de sus atributos, lo que garantiza una autorización adecuada.

Consideraciones de seguridad para desarrolladores

Consideración	Recomendación
Duración del token	Use tokens de acceso de corta duración (de 15 a 60 minutos) y un token de actualización para adquirir nuevos tokens de acceso sin obligar a los usuarios a iniciar sesión.
privilegio mínimo	Solicite la cantidad mínima de ámbitos que una aplicación necesita para minimizar el riesgo de posibles daños causados por tokens comprometidos.
Validación del token	Valide siempre los tokens para reducir los riesgos de seguridad.
Almacenamiento del token	Nunca almacene tokens confidenciales en localStorage o sessionStorage. Use cookies HttpOnly seguras o almacenamiento seguro de sesión en el backend.

Desarrollar aplicaciones seguras requiere comprender la diferencia entre autenticación y autorización:

Concepto	¿Qué resuelve?	Protocolo/token
Authentication	Verificación de identidades	OpenID Connect, token de identificación
Autorización	Control de acceso	OAuth 2.0, token de acceso

Lista para realizar la implementación

• Usar OpenID Connect para la autenticación del usuario
• Usar OAuth 2.0 para la autorización delegada
• Validar los JWT del lado del servidor en cada solicitud de API
• Devolver 401 para errores de autenticación y 403 para denegaciones de autorización
• Utilizar el flujo de código de autorización con PKCE
• Almacenar tokens de forma segura (cookies HttpOnly)
• Usar tokens de acceso de corta duración con rotación de tokens de actualización

Para entender más a fondo los tipos de tokens, conozca la diferencia entre tokens de identificación y tokens de acceso.

El uso de un servicio como Auth0 puede simplificar la implementación de la autenticación y la autorización, y permitir a los desarrolladores concentrarse en la lógica central de sus aplicaciones. Explore nuestra serie de Introducción a IAM para conocer más temas relacionados con la gestión de identidades y accesos.

Más información

Estos materiales tienen únicamente fines informativos generales. Usted es responsable de obtener orientación de seguridad, de privacidad, de cumplimiento o empresarial de sus propios asesores profesionales, y no debe confiar solamente en la información suministrada aquí.