Identidad y acceso: autenticación, autorización, OAuth 2.0 y OpenID Connect

Autenticación y autorización

Cada solicitud a la plataforma de reparto de comida plantea dos preguntas distintas. La autenticación pregunta ¿quién es? y se responde con evidencias: una contraseña, una passkey, un certificado, un token firmado. La autorización pregunta ¿puede hacer esto, con esto, ahora? y se responde con políticas: este cliente puede leer este pedido porque lo hizo él; este repartidor puede ver esta dirección de recogida porque el reparto le está asignado. HTTP también las separa: 401 Unauthorized significa que la solicitud carece de una autenticación válida, mientras que 403 Forbidden significa que se sabe quién llama, pero no tiene permiso.

La distinción importa para la arquitectura porque las dos se resuelven en lugares distintos. La autenticación es mejor centralizarla en un único proveedor de identidad (IdP) en el que confíen todas las aplicaciones, de modo que las reglas de contraseñas, la autenticación multifactor, la recuperación de cuentas y el bloqueo se implementen una sola vez. La autorización es distribuida por naturaleza: solo el servicio de pedidos sabe a quién pertenece un pedido, así que la decisión final sobre un pedido debe tomarse allí, aunque antes se hagan comprobaciones gruesas en el API gateway. La mayoría de las brechas de control de acceso del OWASP Top 10 proceden de confundir las dos: un endpoint que comprueba que el token es válido y luego devuelve cualquier objeto cuyo ID reciba.

Contraseñas, autenticación multifactor y passkeys

Las contraseñas siguen siendo el autenticador más común, y las Digital Identity Guidelines del NIST son las reglas más seguidas para ellas. La revisión 4 de SP 800-63B, publicada en julio de 2025, invierte varias costumbres arraigadas. La longitud importa más que la composición: una contraseña usada como único factor debe tener al menos 15 caracteres (al menos 8 cuando solo se usa como parte de una autenticación multifactor), y los verificadores deben aceptar al menos 64 caracteres, incluidos espacios y Unicode. Los verificadores no deben imponer reglas de composición, como exigir un dígito y un símbolo, que hacen las contraseñas más difíciles de recordar sin hacerlas mucho más difíciles de adivinar. Deben comprobar las contraseñas nuevas contra una lista de bloqueo de contraseñas comunes, previsibles y filtradas. No deben forzar cambios periódicos, solo un cambio cuando haya indicios de que la contraseña está comprometida. Deben permitir los gestores de contraseñas y deberían permitir pegar, no deben ofrecer pistas de contraseña legibles antes de iniciar sesión y no deben pedir preguntas de seguridad. Los intentos fallidos deben tener un límite de tasa.

La autenticación multifactor (MFA) combina factores de distinto tipo: algo que sabes (una contraseña), algo que tienes (un teléfono o una llave de seguridad) y algo que eres (una huella dactilar, que normalmente solo se usa para desbloquear un dispositivo). Frena la mayor parte del relleno de credenciales (credential stuffing), en el que los atacantes prueban pares de usuario y contraseña filtrados de otros sitios. No todos los segundos factores son iguales: los códigos de un solo uso enviados por SMS pueden robarse mediante el duplicado de SIM (SIM swapping), y ningún código de un solo uso, venga de un SMS o de una app de autenticación, resiste el phishing, porque se puede engañar al usuario para que lo escriba en un sitio falso que lo reenvía de inmediato. Por eso las directrices del NIST exigen que los servicios con nivel de garantía de autenticación 2 ofrezcan al menos una opción resistente al phishing, y que los de nivel 3 la usen.

Una passkey (llave de acceso) es la opción resistente al phishing que la mayoría de los usuarios puede usar de verdad. Las passkeys son credenciales FIDO2, basadas en la Web Authentication API (WebAuthn) del W3C y en el Client to Authenticator Protocol (CTAP) de la FIDO Alliance. En el registro, el dispositivo del usuario crea un nuevo par de claves para ese sitio web; el servidor solo guarda la clave pública. Al iniciar sesión, el servidor envía un desafío aleatorio y el dispositivo lo firma con la clave privada después de que el usuario lo desbloquee con una huella, la cara o un PIN. Como el navegador vincula la credencial al origen del sitio web, un sitio de phishing que lo imite no puede obtener una firma válida, y como el servidor no guarda ningún secreto compartido, una brecha en la base de datos no proporciona nada que un atacante pueda reutilizar. Las passkeys pueden estar vinculadas a un dispositivo (en una llave de seguridad de hardware) o sincronizarse entre los dispositivos de un usuario mediante una plataforma o un gestor de contraseñas; la guía del NIST de 2025 acepta las passkeys sincronizadas en el nivel 2, mientras que el nivel 3 exige una clave que no pueda exportarse.

El punto débil arquitectónico de todo esquema de autenticación es la recuperación de cuentas. Si una passkey perdida puede sustituirse haciendo clic en un enlace enviado por correo electrónico, la fortaleza de todo el sistema es la de la cuenta de correo. Los flujos de recuperación merecen su propio modelo de amenazas, límites de tasa, avisos a los demás dispositivos del usuario y, en las cuentas de alto valor, esperas o comprobaciones humanas.

Sesiones y tokens

Una vez que el usuario se ha autenticado, el sistema debe reconocer sus solicitudes posteriores sin volver a preguntar. Hay dos diseños básicos. En una sesión del lado del servidor, el servidor guarda la sesión (usuario, expiración, quizá roles) y da al navegador un identificador de sesión largo y aleatorio en una cookie. En un diseño de token autocontenido, el emisor firma un token que lleva las afirmaciones (claims), normalmente un JSON Web Token (JWT, RFC 7519), y cualquier servicio que tenga la clave pública del emisor puede validarlo sin hacer una consulta.

Para las aplicaciones de navegador, es difícil superar una sesión del lado del servidor en una cookie marcada como HttpOnly (invisible para JavaScript), Secure (solo HTTPS) y SameSite. Las aplicaciones de una sola página usan cada vez más un backend for frontend (BFF): el navegador solo guarda una cookie de sesión para su propio backend pequeño, que guarda los tokens de OAuth y llama a las API en su nombre, un enfoque que recomienda la guía del grupo de trabajo OAuth del IETF para aplicaciones basadas en navegador. Los JWT brillan entre servicios y en las apps móviles, donde una comprobación sin estado en cada salto evita un cuello de botella central.

import jwt  # PyJWT
from jwt import PyJWKClient

ISSUER = "https://id.fooddelivery.example/"
jwks = PyJWKClient(ISSUER + ".well-known/jwks.json")  # issuer's public keys

def verify_access_token(token: str) -> dict:
    signing_key = jwks.get_signing_key_from_jwt(token)
    return jwt.decode(
        token,
        signing_key.key,
        algorithms=["RS256"],      # pinned: never read from the token header
        audience="orders-api",      # the token must be meant for this API
        issuer=ISSUER,
        options={"require": ["exp", "iat", "sub"]},
    )  # raises an exception on any failure: fail closed

OAuth 2.0: autorización delegada

OAuth 2.0 (RFC 6749, 2012) resuelve un problema concreto: permitir que una aplicación actúe en nombre de un usuario sin conocer su contraseña. Antes de OAuth, un servicio que quería importar tus contactos te pedía la contraseña de tu correo electrónico. OAuth define cuatro roles: el propietario del recurso (el usuario), el cliente (la aplicación que quiere acceder), el servidor de autorización (que autentica al usuario, le pide su consentimiento y emite los tokens) y el servidor de recursos (la API que guarda los datos). El cliente recibe un token de acceso limitado por ámbitos (scopes) (como orders:read), una vida útil y una audiencia, y a menudo un token de actualización (refresh token) para obtener nuevos tokens de acceso sin volver a preguntar al usuario.

OAuth define varias formas, llamadas concesiones (grants), de obtener un token. Para cualquier aplicación que actúe en nombre de un usuario, ya sea una app web del lado del servidor, una app de una sola página o una app móvil, la concesión recomendada es el flujo de código de autorización con PKCE (Proof Key for Code Exchange, RFC 7636, 2015). Primero, el cliente crea un code_verifier aleatorio y envía solo su hash SHA-256, el code_challenge, cuando redirige al usuario al servidor de autorización. Después de que el usuario inicie sesión y dé su consentimiento, el servidor de autorización lo redirige de vuelta con un código de autorización de corta duración. A continuación, el cliente canjea el código por tokens en una solicitud directa por el canal trasero (back channel), enviando el verificador original; el servidor comprueba que su hash coincide con el desafío. Un atacante que intercepte el código, por ejemplo una app móvil maliciosa registrada para la misma dirección de redirección, no puede canjearlo sin el verificador, que nunca salió del cliente.

La concesión de credenciales de cliente cubre el caso en el que no hay usuario: un servicio obtiene un token con su propia autoridad, por ejemplo el servicio de despacho cuando llama a la API de un proveedor de mapas asociado, o el sistema de un socio cuando llama a la API de estado de pedidos de la plataforma. El cliente debería autenticarse ante el endpoint de tokens con una clave privada (una aserción JWT firmada) o con TLS mutuo (RFC 8705) en lugar de con un secreto compartido. Hoy se desaconsejan dos concesiones más antiguas: la concesión implícita, que devolvía los tokens en la URL del navegador, y la concesión de credenciales de contraseña del propietario del recurso, en la que el cliente recogía la contraseña del usuario y, por tanto, anulaba el propósito de OAuth. La RFC 9700, la OAuth 2.0 Security Best Current Practice publicada en enero de 2025, recoge estas lecciones, incluidas la coincidencia exacta de las direcciones de redirección y los tokens restringidos al remitente.

OAuth 2.1 reúne OAuth 2.0 y estas buenas prácticas en un solo documento: PKCE es obligatorio en el flujo de código de autorización, se eliminan las concesiones implícita y de contraseña, las direcciones de redirección deben coincidir exactamente y los tokens Bearer ya no pueden enviarse en las cadenas de consulta de las URL. En el momento de escribir esto (octubre de 2026), sigue siendo un Internet-Draft del IETF (borrador 16, septiembre de 2026), no una RFC, pero sus reglas ya describen lo que hacen los servidores de autorización bien gestionados.

OpenID Connect, inicio de sesión único y SAML

OAuth emite tokens de acceso para las API; por sí solo, no le dice al cliente quién es el usuario. Usar un token de acceso como prueba de inicio de sesión es un error bien conocido, porque un token emitido para una aplicación puede reutilizarse en otra que no compruebe su audiencia. OpenID Connect (OIDC, Core 1.0, 2014) añade la capa de identidad que faltaba. Con el ámbito openid, el servidor de autorización, que ahora actúa como proveedor de OpenID, devuelve también un token de ID: un JWT firmado para el cliente, que indica el emisor, el identificador estable del usuario (sub), la audiencia (el ID del cliente), las horas de emisión y de expiración, un nonce que lo vincula a este inicio de sesión y, opcionalmente, cómo y cuándo se autenticó el usuario. OIDC también estandariza un endpoint de información del usuario y unos documentos de descubrimiento que publican los endpoints y las claves de firma del proveedor. La regla práctica: el token de ID es para el cliente, para saber quién ha iniciado sesión; el token de acceso es para la API, para autorizar las llamadas.

El inicio de sesión único (SSO) viene de forma natural: en cuanto un usuario tiene una sesión con el proveedor de identidad, cada aplicación que confía en él puede iniciarle la sesión sin pedirle otra contraseña, y desactivar la cuenta en un solo lugar corta el acceso en todas partes. En las empresas, el SSO a menudo sigue usando SAML 2.0 (un estándar de OASIS de 2005), que intercambia aserciones XML firmadas a través del navegador. La plataforma de reparto de comida podría usar OIDC para sus propias apps y aceptar SAML de las grandes cadenas de restaurantes que quieren que su personal inicie sesión en el portal de restaurantes con sus cuentas corporativas. El alta y la baja de cuentas en los distintos sistemas suele automatizarse con SCIM (RFC 7643 y 7644).

Modelos de autorización: RBAC, ABAC y relaciones

La autenticación le dice al sistema quién llama; un modelo de autorización decide qué puede hacer. Predominan tres modelos, y los sistemas reales suelen combinarlos.

El control de acceso basado en relaciones se conoce sobre todo por el artículo de Google de 2019 sobre Zanzibar, el sistema global de autorización que hay detrás de Google Drive, Calendar, YouTube y muchos otros productos. Zanzibar almacena tuplas de relación de la forma object#relation@user, evalúa los permisos siguiéndolas y usa tokens de consistencia para que una comprobación de permisos nunca se evalúe con datos más antiguos que el contenido que protege, el llamado problema del nuevo enemigo (new enemy problem): quitar a alguien de un documento y después añadir contenido sensible no debe permitirle verlo. Entre los sistemas de código abierto inspirados en él están SpiceDB, OpenFGA y Ory Keto.

Sea cual sea el modelo, conviene separar el punto de decisión de políticas (PDP), que evalúa la política y responde permitir o denegar, del punto de aplicación de políticas (PEP), el código del gateway o del servicio que hace la pregunta y aplica la respuesta. Los motores de políticas de uso general, como Open Policy Agent (OPA, un proyecto graduado de la Cloud Native Computing Foundation, con políticas escritas en su lenguaje Rego) y Cedar (liberado como código abierto por Amazon Web Services en 2023), permiten que la política viva en archivos versionados, se pruebe como el código y se evalúe dentro del proceso o como sidecar, cerca del servicio. Una organización en capas sensata en la plataforma es esta: el API gateway rechaza las solicitudes sin un token válido o sin el ámbito adecuado (grueso), y cada servicio decide las cuestiones a nivel de objeto con datos que solo él tiene (fino). La autorización rota a nivel de objeto es el primer riesgo del OWASP API Security Top 10 (edición de 2023) precisamente porque la comprobación fina es la que los equipos olvidan.

Identidad de carga de trabajo: cuando quien llama es un servicio

Los servicios se autentican entre sí con mucha más frecuencia que las personas inician sesión, y sin embargo las credenciales de servicio suelen ser las más débiles: una clave de API de larga duración en una variable de entorno, compartida por varios servicios y nunca rotada. Si esa clave se filtra a través de un log, un repositorio o una imagen de contenedor, el atacante se convierte en el servicio. La identidad de carga de trabajo sustituye esos secretos por identidades que la plataforma emite para la carga de trabajo en ejecución, después de haber verificado qué carga de trabajo es.

El estándar abierto es SPIFFE (Secure Production Identity Framework for Everyone), un proyecto graduado de la Cloud Native Computing Foundation. Nombra cada carga de trabajo con un URI como spiffe://fooddelivery.example/ns/prod/sa/orders y emite un documento de corta duración, rotado automáticamente, que lo demuestra, llamado SVID, normalmente un certificado X.509 (o un JWT). Su implementación de referencia, SPIRE, verifica mediante atestación el nodo y la carga de trabajo (por ejemplo, su namespace y su cuenta de servicio de Kubernetes) antes de emitir la identidad. Después, los servicios usan los certificados para el TLS mutuo, de modo que el servicio de pagos sabe que quien llama es de verdad el servicio de pedidos y puede autorizar según la identidad. Las plataformas en la nube ofrecen equivalentes (roles para cargas de trabajo, identidades administradas, federación de identidades de carga de trabajo), y los sistemas de CI como GitHub Actions pueden canjear un token OIDC firmado por credenciales de nube de corta duración, de modo que los pipelines no necesitan claves almacenadas. Cómo se usan estas identidades para construir una red sin confianza implícita es el tema de zero trust.