El estado que continúa una autenticación también puede continuar un error
Una aplicación de pagos autentica a Elena y devuelve Set-Cookie: __Host-sid=.... Diez minutos después, el navegador envía la cookie y el servidor permite aprobar una transferencia. Para el equipo, «la cookie identifica a Elena». Esa frase mezcla al menos cuatro objetos: la cookie es una representación en el agente de usuario; el valor puede ser un secreto de sesión; el servidor conserva el estado que ese secreto resuelve; y la política decide si el contexto actual permite la operación.
El mismo error aparece con token. Un token puede ser un artefacto opaco, una assertion (declaración verificable), un access token para una Application Programming Interface (API), un JSON Web Token (JWT) con claims (afirmaciones) codificados o un secreto que mantiene una sesión. El formato no determina por sí solo quién lo emitió, a quién va dirigido, quién lo puede presentar, qué acción habilita, durante cuánto tiempo funciona ni cómo se revoca.
Este capítulo construye un modelo operativo para no comprimir esas preguntas. Primero distingue credencial, token, cookie, secreto de sesión y estado del servidor. Después reconstruye la entrega por Hypertext Transfer Protocol (HTTP), separa bearer de proof-of-possession (PoP, prueba de posesión), modela expedición, expiración, inactividad, revocación y rotación, y finalmente diagnostica fixation, replay e invalidación. OAuth 2.0 aparece sólo como frontera: los detalles de autorización delegada y de sus access tokens pertenecen al capítulo 45.
Cinco objetos, lugares distintos y autoridades separadas
Una credencial es una estructura administrada por una autoridad de identidad que liga una identidad o identificador a uno o más autenticadores. El capítulo 37 fijó esa relación; aquí importa que una credencial no es sinónimo de cookie. Una contraseña, una clave privada, una credencial almacenada por un proveedor y la sesión creada después de autenticarse ocupan lugares distintos en el ciclo de vida.
Un token es un contenedor o valor que un protocolo transporta entre participantes. Puede ser legible o completamente opaco, autocontenido o una clave de búsqueda. Si contiene datos firmados, esos datos siguen siendo claims que un receptor debe interpretar bajo un emisor, audiencia, tiempo y política. Si sólo contiene un nonce aleatorio, el significado vive principalmente en el estado del servidor. “Autocontenido” describe dónde viajan datos; no significa que el receptor deba aceptar esos datos sin validar contexto, tiempo y lifecycle.
Una cookie es un par nombre/valor acompañado de atributos que el servidor entrega mediante Set-Cookie; el agente de usuario almacena metadatos y decide si devuelve el valor en Cookie. HTTP State Management no convierte la cookie en una credencial ni en una autorización: define una forma de mantener estado entre peticiones. RFC 6265, §§4–5
Un secreto de sesión es el valor que enlaza el software del subscriber (por ejemplo, navegador o aplicación) con el session host (Relying Party o Credential Service Provider). NIST permite presentarlo directamente o demostrar su posesión mediante criptografía; la continuidad de la sesión se basa en ese secreto, no en conservar de nuevo la contraseña o el autenticador original. NIST SP 800-63B-4, §5.1
El estado del servidor es el registro que el host usa para resolver el secreto y aplicar lifecycle: cuenta, método de autenticación, assurance, emisión, último uso, vencimiento absoluto, estado de revocación, rotación y contexto permitido. Un diseño stateless puede codificar parte del estado en un token autenticado, pero no elimina la necesidad de política ni la capacidad de invalidar. Un diseño stateful puede invalidar buscando y marcando un registro; ambos deben responder qué se acepta y por qué. Esta es una distinción de diseño editorial: ni RFC 7519 ni RFC 6265 convierten “stateless” en una garantía de revocación o “stateful” en una garantía de consistencia.
Desliza horizontalmente para consultar todas las columnas.
La autoridad también debe quedar explícita. El agente de usuario controla el almacenamiento y el envío según atributos y políticas locales; el servidor produce Set-Cookie, valida un token y mantiene o resuelve el estado; un emisor de identidad puede producir una assertion; un punto de decisión autoriza una acción. Que un componente pueda leer un valor no significa que pueda afirmar su semántica.
Desliza horizontalmente para leer el diagrama a tamaño completo.
El viaje de una cookie no es el ciclo de vida de una sesión
La secuencia mínima de una aplicación web puede escribirse así:
POST /login HTTP/1.1
Host: pagos.example.test
Content-Type: application/x-www-form-urlencoded
credential=resultado-de-autenticacion
HTTP/1.1 303 See Other
Location: /dashboard
Set-Cookie: __Host-sid=valor-opaco; Secure; HttpOnly; Path=/; SameSite=Lax
El contexto es sintético: el valor no es un secreto real y el credential representa un resultado ya verificado. La parte relevante es causal. El host autentica, crea un registro de sesión, genera un secreto con un generador aprobado, lo entrega por un canal protegido y lo vincula con una cookie. La respuesta no «convierte» una cookie en autenticación: el servidor decide que ese valor resuelve una sesión que nació de un evento autenticado.
En la siguiente petición, el navegador aplica reglas de alcance. No envía todas sus cookies: considera host, dominio, path, tipo de conexión, contexto same-site y vencimiento. El servidor recibe un header que puede contener varios pares, resuelve el valor según su propio contrato y recién entonces consulta estado, timeout y política. HttpOnly controla la exposición a interfaces de scripting del agente; no impide que un navegador envíe la cookie en una petición que cumpla el alcance. Secure restringe su envío a conexiones consideradas seguras, pero la especificación de cookies advierte que no proporciona integridad frente a todos los atacantes activos de red. draft-ietf-httpbis-rfc6265bis-22, §§4.1.2.5–4.1.2.6 y §8.1
La revisión 6265bis más reciente está en cola editorial de la RFC Editor y aún es un Internet-Draft. Por eso el capítulo distingue su estado: RFC 6265 continúa siendo el estándar publicado; el borrador -22 documenta la evolución actual de las reglas de cookies y se cita como borrador, no como requisito de una RFC ya aprobada. Estado del documento draft-ietf-httpbis-rfc6265bis-22
Los atributos son restricciones de entrega, no una política completa de sesión:
Secureevita que el agente envíe la cookie por conexiones no seguras según las reglas de cookies. El servidor todavía necesita impedir downgrades y configurar transporte seguro.HttpOnlyreduce la exposición a APIs de scripting, pero no neutraliza un servidor que acepta una petición manipulada ni elimina cross-site scripting (XSS).PathyDomainlimitan dónde se devuelve el valor, pero el path no es una frontera de integridad entre aplicaciones del mismo host y el dominio puede permitir que un subdominio escriba un valor dirigido a otro.SameSite=Strict,LaxoNonecambian la entrega según el contexto same-site/cross-site. Son defensa en profundidad contra ciertos ataques de falsificación de petición entre sitios (CSRF), no una prueba de intención ni una sustitución universal de un token CSRF. El servidor debe verificar una comprobación de intención coherente; no debe usar métodos HTTP seguros para mutaciones.Max-AgeyExpiresinfluyen en el almacenamiento del agente. Borrar o expirar una cookie no invalida automáticamente el registro del servidor.
El agente sólo acepta los prefijos desde un origen seguro. __Secure- requiere además Secure y puede llevar Domain; __Host- requiere Secure, Path=/, cookie host-only y ausencia de Domain. Estas restricciones reducen algunas formas de fijar una cookie desde un subdominio, pero no transforman el valor en secreto de prueba de posesión ni producen revocación. El capítulo no pretende reproducir aquí las reglas de capitalización del algoritmo de aceptación. draft-ietf-httpbis-rfc6265bis-22, §§4.1.3.1–4.1.3.2 y 5.4
Bearer y proof-of-possession cambian el significado de robar un token
Un valor es bearer cuando el receptor concede autoridad a quien lo presenta correctamente, sin exigir una demostración adicional de que esa parte controla una clave vinculada. El modelo es útil y común: si un atacante copia el valor de un header, cookie o almacenamiento de aplicación, puede intentar presentarlo hasta que el host lo rechace por expiración, revocación, audience, binding u otra política. El estándar de bearer HTTP describe precisamente esa semántica: la posesión del token es suficiente para usarlo dentro del alcance concedido. En el perfil HTTP de RFC 6750, Transport Layer Security (TLS) es obligatorio, se prefiere Authorization: Bearer y el transporte en URI/query debe evitarse salvo necesidad documentada porque expone el valor a historial, logs e intermediarios. Eso acota ese perfil; no convierte todo token genérico en un access token OAuth. RFC 6750, §§1.2–1.3 y 5.1–5.3
Proof-of-possession añade una prueba criptográfica ligada al uso. El portador presenta el token y demuestra, además, control de una clave o secreto asociado; un valor copiado sin esa clave no satisface el protocolo. La propiedad no es binaria ni universal: hay que identificar qué mensaje, audiencia, método, URI, canal o contexto se liga, qué clave verifica el receptor y cómo se rota o revoca esa clave. NIST contempla secretos de sesión usados con pruebas de posesión y exige, aun así, aplicar los límites de lifetime de la sesión. NIST SP 800-63B-4, §5.1
En diseños OAuth, Demonstrating Proof-of-Possession at the Application Layer (DPoP) es un perfil específico que liga una presentación a una clave y a datos de la petición. Sus comprobaciones incluyen método y URI (htm, htu), vínculo al access token (ath) cuando corresponde, nonce y límites de replay; no proporcionan integridad general del cuerpo ni de todos los headers. Una prueba capturada puede repetirse contra el mismo endpoint dentro de su ventana si el receptor no exige nonce o consumo, y el robo de la clave privada —incluido mediante código no confiable en el cliente— mantiene riesgo. PoP tampoco sustituye autorización. No pertenece aquí la reconstrucción de OAuth, sus grants ni sus scopes; el capítulo 45 explicará esos objetos. Este capítulo sólo necesita el contraste: Authorization: Bearer ... y un mecanismo PoP no tienen el mismo modelo de robo, replay y almacenamiento. RFC 9449, §§1–4, 8–9 y 11.1–11.7
El formato JWT tampoco cambia por sí solo esa clasificación. RFC 7519 define un JWT como una forma compacta de representar claims transferidos entre partes. Sus claims registrados incluyen iss (issuer), sub (subject), aud (audience), exp (expiration time), nbf (not before), iat (issued at) y jti (JWT ID); el receptor debe validar la aplicación concreta y no sólo decodificar JSON. Un JWT firmado puede ser bearer; la firma verifica integridad y autenticidad relativa a una clave cuyo uso y vínculo con el issuer el receptor haya validado. No vincula automáticamente el token al presentador ni lo revoca antes de exp. sub puede ser localmente único dentro del issuer o globalmente único según el perfil, pero el receptor no debe asumir una de esas propiedades: valida y resuelve (issuer, subject) conforme a su contrato. RFC 7519, §§1, 4.1 y 7
La práctica de aceptar JWT tiene puertas distintas. RFC 8725 §§2.1–2.3 describen amenazas de algoritmos, claves y composición; §3.1 exige una allowlist de algoritmos permitidos y, cuando se usa cifrado, de algoritmos de cifrado. §3.8 exige validar que iss y las claves correspondan al issuer esperado; §3.9 exige validar aud cuando el receptor tiene una audiencia prevista; §§3.11–3.12 recomiendan separar tipos de JWT y reglas mutuamente excluyentes para que un token destinado a una función no sea aceptado en otra. Además, headers o claims como kid, jku y x5u son entrada no confiable: no deben conducir a consultas SQL/LDAP o fetches arbitrarios; sus valores y destinos requieren validación y allowlists. Estas comprobaciones son de validación contextual, no una revocación. La guía no convierte el JWT en sesión ni prescribe un almacén de revocación. RFC 8725, §§2.1–2.3, 2.9, 3.1, 3.8–3.12
Desliza horizontalmente para leer el diagrama a tamaño completo.
Qué debe contener un estado de sesión defendible
Un registro de sesión no necesita guardar la contraseña ni la assertion completa. Debe permitir contestar por qué una petición se acepta y cómo se terminará. El siguiente YAML es un modelo sintético no normativo; los nombres no son convenciones interoperables:
session_handle: sess-h-7f3c # referencia no reutilizable; no es el secreto
secret_digest: digest-no-reversible # opción local, sólo si el modelo lo requiere
rp_account: payroll-2048
auth_event: auth-91aa
authenticator_context: aal2-declarado
issued_at: 2026-10-04T14:00:00Z
last_accepted_request_at: 2026-10-04T14:17:10Z # actividad técnica aceptada
last_reauth_at: 2026-10-04T14:00:00Z # evidencia de reautenticación
absolute_expires_at: 2026-10-04T18:00:00Z
idle_expires_at: 2026-10-04T15:17:10Z
generation: 4
status: active
session_handle es correlación; no debe ser un bearer reutilizable. secret_digest es una opción de diseño, no una obligación universal: sólo se usa si la implementación puede protegerlo y necesita comparación, y nunca se copia a logs como material de presentación. El host debe poder encontrar el registro sin convertirlo en un segundo canal de bearer. last_accepted_request_at mide actividad técnica aceptada; last_reauth_at conserva la evidencia temporal de reautenticación y no debe sustituirse por un heartbeat. issued_at y los dos vencimientos separan antigüedad total de inactividad. generation permite detectar un secreto anterior tras una rotación. status hace visible la transición a revoked, expired o terminated. El contexto de autenticación acota assurance; no prueba que la persona siga presente ni concede autorización para cualquier acción.
En un sistema distribuido, la decisión también depende de frescura. Si el nodo A marca una sesión revocada y el nodo B conserva una copia durante treinta segundos, la arquitectura tiene una ventana de aceptación. No se debe describir como invalidación instantánea sin medir la propagación. Las opciones son compartir estado con una consistencia adecuada, usar una generación consultable, reducir la vida del token, exigir revalidación para acciones sensibles o aceptar explícitamente la ventana residual. Esta ventana es una síntesis de diseño: RFC 6265 y NIST no especifican la consistencia de una caché concreta.
El almacenamiento es una decisión de frontera. Un secreto bearer de sesión expuesto a JavaScript, logs, trazas, historial de URLs o telemetría de terceros tiene más rutas de copia. NIST indica que los secretos de sesión no deberían colocarse en ubicaciones inseguras como Local Storage por la exposición potencial a cross-site scripting; también exige un mínimo de 64 bits y generación con un generador aprobado para los secretos que enlazan la sesión. NIST SP 800-63B-4, §5.1
El browser cookie es una opción de transporte y aislamiento parcial, no una caja fuerte. Para mantenimiento de sesión, NIST pide acceso sólo por canales seguros, el menor alcance práctico de hostnames y paths, recomienda HttpOnly, una expiración cercana a la validez de la sesión, prefijo __Host-, Path=/, SameSite=Lax o Strict, y una cadena opaca sin información personal en claro. También advierte que la expiración del navegador no debe ser el mecanismo que haga cumplir el timeout: el host debe rechazar el secreto por estado y tiempo. NIST SP 800-63B-4, §5.1.1
Expiración, inactividad, revocación y rotación son transiciones distintas
El tiempo de vida de una sesión tiene dos límites que se confunden con frecuencia. El overall timeout limita la duración desde la autenticación o reautenticación. El inactivity timeout termina una sesión sin actividad durante un intervalo. Actividad válida puede reiniciar el contador de inactividad, pero no necesariamente el límite absoluto. Una reautenticación exitosa durante la sesión reinicia ambos límites; la política determina cuándo se exige y qué autenticación permite. NIST exige que al expirar cualquiera se termine la sesión y que la organización documente los límites conforme al nivel de assurance, endpoint y entorno. NIST SP 800-63B-4, §5.2
Expiración es una decisión temporal: el host considera que now >= absolute_expires_at o now >= idle_expires_at. La cookie puede seguir almacenada, y un token JWT puede todavía decodificarse, pero la autoridad ya no debe aceptarlos. Un Expires pasado ayuda a limpiar el cliente; no reemplaza la comparación de tiempo del servidor.
Revocación es una decisión explícita antes del vencimiento natural: logout, pérdida o compromiso del secreto, suspensión de cuenta, cambio de riesgo, baja de un dispositivo o invalidación administrativa. Revocar el registro de servidor es diferente de pedir al navegador que elimine la cookie. Cuando el sistema no tiene introspección en cada petición, debe declarar la ventana entre revocación y rechazo.
Rotación sustituye un secreto o generation por otro. En una rotación posterior a autenticación, el host emite un secreto nuevo y deja de aceptar el anterior conforme a una política de solapamiento. Una ventana corta y controlada puede tolerar carreras entre pestañas o nodos; aceptar indefinidamente ambos valores no es rotación efectiva. La rotación también debe evitar que un atacante que fija un identificador antes del login conserve el mismo valor después de elevarse la autoridad. La obligación de regenerar tras un cambio de autoridad es la aplicación de diseño de la amenaza de fixation; el borrador describe la amenaza, no una API universal de rotación. draft-ietf-httpbis-rfc6265bis-22, §8.4
Inactividad no es sinónimo de ausencia humana. Un script, una precarga o una petición automática puede actualizar last_accepted_request_at si la implementación la considera actividad técnica válida. Eso no es evidencia de presencia del subscriber ni de intención. Si la política pretende confirmar presencia, necesita una reautenticación o un mecanismo adicional y debe conservar last_reauth_at por separado. NIST describe la reautenticación periódica como forma de confirmar continuidad de presencia en una sesión, con límites dependientes del nivel y contexto. NIST SP 800-63B-4, §5.2
La federación agrega relojes. La sesión del Identity Provider (IdP), la ventana de una assertion y la sesión local del Relying Party (RP) son estados distintos. Una assertion puede expirar después de que el RP la procese; cerrar la sesión del IdP no termina automáticamente todas las sesiones locales. El RP sigue siendo autoridad para decidir si la frescura y reautenticación cumplen su política. La señalización compartida puede comunicar eventos de terminación, suspensión o compromiso, pero sus eventos, contenido y comportamiento esperado deben estar documentados en el trust agreement. NIST SP 800-63C-4, §4.7 y §4.8
Desliza horizontalmente para leer el diagrama a tamaño completo.
Fijación: el identificador que sobrevive al cambio de autoridad
Session fixation ocurre cuando un atacante consigue que la víctima use un identificador que el atacante ya conoce; después la víctima autentica o aporta información a ese contexto, y el atacante reusa el mismo identificador para obtener la autoridad resultante. El borrador de HTTP State Management describe esa secuencia explícitamente. draft-ietf-httpbis-rfc6265bis-22, §8.4
El fallo no es que el identificador sea predecible solamente. Incluso un identificador aleatorio puede fijarse si una aplicación acepta el valor anterior después de login. La defensa central es regenerar el secreto y la identidad del registro cuando cambia la autoridad: login, elevación de privilegio, recuperación, cambio de cuenta o binding de un autenticador. El servidor debe retirar el registro anterior, no sólo sobrescribir la cookie del navegador, y debe comprobar que el nuevo valor no se haya elegido por el cliente.
Ejemplo: GET /start crea sid=A en un navegador controlado por el atacante. La víctima recibe sid=A, inicia sesión como Elena y el servidor asocia A a payroll-2048. Si el atacante presenta A, la autenticación de Elena quedó incorporada al identificador que conocía. En el diseño corregido, el login invalida A, crea B con una nueva generación y devuelve B sólo por el canal protegido. Una respuesta con Set-Cookie no es evidencia suficiente: hay que observar rechazo de A en el servidor.
La fijación también puede provenir de ambigüedad entre nombres, paths, dominios o capas. Dos cookies con el mismo nombre y distintos paths pueden llegar juntas; un proxy puede interpretar el header de manera distinta al framework; un subdominio puede establecer un valor de dominio compartido. El diagnóstico registra nombre, atributos efectivos, origen de la respuesta, valor resuelto y política de selección, sin almacenar el secreto completo.
Replay: un valor válido presentado fuera de su contexto
Replay es volver a presentar una representación que fue válida en otra interacción. En un bearer token, copiar el valor puede ser suficiente hasta que expire o sea revocado. Firmar o cifrar el token no impide por sí mismo transplantarlo a otro agente ni presentarlo más tarde; el borrador de cookies lo señala para valores protegidos. draft-ietf-httpbis-rfc6265bis-22, §8.3
La resistencia al replay depende del mecanismo que el receptor pueda verificar: nonce único y estado de consumo, jti con registro de uso, ventana temporal estrecha, audiencia y método ligados, rotación, revocación, channel binding o proof-of-possession. jti es un identificador de JWT; sólo apoya detección de replay si existe estado que registra usos, y un nonce sólo es útil si el protocolo exige que sea fresco y esté ligado a la transacción. Cada control tiene alcance. Un exp limita tiempo, pero no evita dos usos dentro de la ventana. Una audience correcta evita uso en otro receptor, pero no duplica la unicidad de la presentación. Un token PoP reduce utilidad del valor robado, pero no corrige una clave privada robada ni una política que permita reusar la misma prueba. RFC 7519, §4.1.7
La cookie añade ambient authority: el navegador puede adjuntarla a una petición que un sitio remoto provoca, aunque el sitio remoto no conozca el valor. Por eso una aplicación que usa cookies para sesión debe proteger operaciones que cambian estado con métodos y comprobaciones de intención apropiadas. NIST exige que el contenido POST/PUT incluya un identificador de sesión que el RP verifique para protegerse contra CSRF; el borrador de cookies recomienda defensas server-side adicionales y advierte que SameSite no cubre todos los recorridos same-site. Un token CSRF u otra comprobación de intención pertenece a la aplicación, no al atributo de cookie. NIST SP 800-63B-4, §5.1 draft-ietf-httpbis-rfc6265bis-22, §§8.2 y 8.8
Una petición POST /payments/approve con cookie válida ilustra la frontera. El navegador aporta una sesión; no aporta por sí mismo una orden intencional de aprobar ese pago. El servidor verifica autenticidad del contexto, CSRF, estado del recurso, principal efectivo, recencia requerida y política de autorización. El capítulo 40 estudia modelos de autorización; aquí sólo se impide que la sesión sea tratada como permiso universal.
Desliza horizontalmente para leer el diagrama a tamaño completo.
Invalidar significa cortar cada ruta que conserva autoridad
La invalidación correcta es un grafo, no un botón de logout. Para una sesión stateful, el host marca el registro como terminated o revoked, incrementa la generación de cuenta si corresponde, expira la cookie, elimina copias en caché y notifica a los nodos que aún pueden aceptar el secreto. Para un token autocontenido, borrar la cookie no basta. Hay tres puertas separadas: (1) validación criptográfica y contextual (alg, clave, issuer, audience, tipo, nbf/exp); (2) lifetime y replay (exp, jti, nonce, consumo y reloj); y (3) revocación/estado (generation, cuenta, introspección o lista de rechazo). Una audiencia incorrecta no es una revocación; un jti sólo expresa replay si el receptor conserva estado de uso. Para un PoP, también debe considerarse la clave vinculada.
Logout del usuario, expiración por inactividad, revocación administrativa y baja de una cuenta no son el mismo evento. Un logout puede terminar una sesión concreta sin revocar todos los autenticadores. Una cuenta suspendida puede exigir cortar todas sus sesiones y tokens derivados; otras credenciales OAuth quedan fuera del lifecycle de este capítulo. La propagación entre sistemas puede tener una ventana. Una clave rotada puede dejar inválidos tokens que dependen de ella, mientras otras sesiones stateful permanecen activas. La política debe enumerar el alcance de cada transición.
Una respuesta de logout debe ser comprobable con pruebas negativas:
- Presentar el secreto anterior en el mismo nodo debe fallar.
- Presentarlo en otro nodo o región debe fallar tras la latencia documentada.
- Repetir una petición capturada no debe ejecutar de nuevo una operación de un solo uso.
- Reabrir una pestaña con una cookie almacenada debe exigir la política prevista.
- Cambiar estado de cuenta o role debe afectar nuevas decisiones y, si la política lo exige, sesiones ya creadas.
- Un token cuyo
expaún no llegó pero cuya generación fue revocada debe ser rechazado si esa es la garantía declarada.
No se deben usar valores secretos en logs de prueba. Registrar session_handle no reutilizable, hash con propósito limitado sólo cuando el diseño lo proteja, generation, decisión, nodo, razón de rechazo, reloj y trace ID permite reconstruir la transición sin crear un nuevo canal de replay. La razón de rechazo no demuestra por sí sola que otro nodo no aceptó el valor: las pruebas deben cubrir cada ruta de aceptación.
Desliza horizontalmente para leer el diagrama a tamaño completo.
Desliza horizontalmente para leer el diagrama a tamaño completo.
La cookie no es la credencial y el token no es la identidad
Tres errores de lenguaje producen diagnósticos equivocados.
Primero, «la cookie es la credencial». Una cookie de sesión puede transportar un secreto bearer emitido después de autenticar, pero no contiene necesariamente el autenticador ni la prueba de identity proofing. Si se roba, el incidente es de continuidad de sesión; cambiar una contraseña puede no cortar la sesión ya emitida.
Segundo, «el JWT es la identidad». sub puede ser localmente único dentro del issuer o globalmente único según el perfil; no debe asumirse global sólo por aparecer en un JWT ni convertirse en autorización automática. El receptor debe validar issuer, resolver el subject conforme al perfil, verificar audience y contexto y aplicar su propia política. Un JWT válido para una audiencia incorrecta debe rechazarse aunque la firma sea válida.
Tercero, «borrar el token revoca el acceso». La eliminación local sólo afecta esa copia. Revocación requiere que todo receptor que aún pueda aceptar el valor lo rechace dentro del alcance prometido. Para un estado de servidor, eso significa marcar o retirar el registro; para un token autocontenido, mantener una condición de rechazo suficientemente fresca.
La nomenclatura recomendada en un diseño es concreta: password-authenticator, idp-assertion, rp-session-secret, __Host-rp_sid, api-access-token, session-record, key-generation-4. Cada nombre debe indicar función y lifecycle. «Token» sin calificativo queda reservado para una explicación que inmediatamente declare su tipo; refresh-token se menciona sólo como credencial OAuth fuera de alcance.
Límite con OAuth 2.0 y con la autorización delegada
Este capítulo no enseña OAuth 2.0. Un access token de OAuth es una credencial para que una aplicación acceda a recursos protegidos en nombre de una autorización concedida; su relación con el usuario, el cliente, el recurso, scopes, grants, refresh tokens e introspection requiere el capítulo 45. RFC 6750 se cita aquí sólo para fijar la semántica de bearer y no para sustituir ese tratamiento. RFC 6750, §§1–2
Una sesión de navegador del RP y un access token para una API pueden nacer después del mismo login y tener lifetimes diferentes. Invalidar una no implica invalidar la otra. Un ID token de OpenID Connect tampoco se convierte automáticamente en token de sesión local: la semántica de federación y el account linking pertenecen al capítulo 46. La frontera evita usar un mecanismo de transporte como prueba universal de autorización.
Síntesis: modelar la autoridad que continúa
Una sesión es una relación temporal iniciada por autenticación y mantenida por un secreto o prueba de posesión. Una cookie es una forma de almacenar y devolver un valor bajo reglas de agente de usuario. Un token es una representación cuyo tipo, emisor, audiencia, presentación, lifetime y binding deben nombrarse. El estado del servidor resuelve ese valor y aplica la política; si el estado es autocontenido, el receptor sigue necesitando condiciones de rechazo y lifecycle.
La diferencia crítica es entre lo que el cliente transporta y lo que el servidor autoriza. Secure, HttpOnly, SameSite, Path, prefijos y expiración del agente reducen superficies concretas; no sustituyen Transport Layer Security (TLS), protección CSRF, rotación tras cambios de autoridad, expiración server-side, revocación ni reautenticación. Bearer y proof-of-possession cambian la utilidad de un valor robado, pero ninguno vuelve automática la atribución ni la autorización.
El modelo profesional termina con una pregunta verificable: ¿qué evento emitió este secreto, a qué cuenta y contexto quedó ligado, dónde se presentó, qué estado y reloj lo hicieron aceptable, qué transición lo invalida y qué decisión separada autorizó la acción? Si no se pueden contestar esas preguntas sin leer un secreto reutilizable, el diseño conserva autoridad sin una cadena de evidencia defendible.