Cuentas, identidades, credenciales, permisos y sesiones
Este capítulo ofrece un mapa N0–N1 para entender qué significa iniciar una interacción con un servicio sin confundir persona, cuenta, identidad, credencial, permiso o sesión. El caso conductor es una biblioteca digital: Alex ve una pantalla de acceso, entra a una cuenta y solicita leer un documento. Cada palabra responde a una pregunta diferente. Iniciar sesión no concede todos los permisos, y cerrar una interfaz no demuestra que cada sesión haya terminado.
La persona o sujeto es quien actúa o a quien se atribuye una acción en el contexto del sistema. Una cuenta es un registro administrativo que reúne configuración, relaciones y estado. Un principal es la entidad que un sistema reconoce para aplicar decisiones. Una identidad es la representación vinculada a ese principal. Una credencial es una evidencia presentada para autenticar. Autenticación responde quién presenta evidencia; autorización decide qué puede hacer bajo una condición; un permiso expresa una acción permitida sobre un recurso; una sesión es un estado temporal de interacción. Recuperación es el camino para restablecer acceso y no debe confundirse con autorización ordinaria.
Desliza horizontalmente para leer el diagrama a tamaño completo.
Persona, sujeto y cuenta
Alex es una persona; la biblioteca mantiene una cuenta que puede pertenecerle, pero ambas entidades no son idénticas. La cuenta puede tener datos incompletos, delegaciones o cambios administrativos. Una afirmación sobre la persona necesita evidencia distinta de una afirmación sobre el registro de cuenta.
Principal e identidad
El principal es el sujeto técnico al que el sistema aplica una decisión. La identidad es la forma en que el sistema lo reconoce dentro de un contexto. El mismo sujeto puede tener identidades distintas en servicios distintos, y una cuenta puede representar una relación sin demostrar quién controla físicamente cada acción.
Credencial y autenticación
Una credencial es algo presentado para apoyar una afirmación de identidad. Autenticar significa evaluar esa evidencia según reglas del sistema. Ver una cuenta en una pantalla no prueba que la persona que mira sea el principal autenticado; la observación debe situarse en una operación concreta.
Desliza horizontalmente para leer el diagrama a tamaño completo.
Autorización y permiso
Después de autenticar, el sistema decide si el principal puede realizar una acción sobre un recurso. El permiso es específico: leer un documento no implica editarlo, compartirlo ni administrar la cuenta. El login no es un permiso universal.
Sesión como estado
Una sesión reúne contexto temporal de interacción: principal reconocido, servicio, momento y estado de continuidad. Puede existir más de una sesión para el mismo principal. Cerrar una pestaña o una interfaz no demuestra que todas las sesiones, dispositivos o procesos hayan terminado.
Recuperación
Recuperar acceso es un flujo especial para restablecer una relación con la cuenta. No debe tratarse como prueba automática de que todas las acciones futuras están autorizadas. El flujo tiene condiciones, evidencias y límites propios.
Caso de la biblioteca
Alex inicia una interacción y ve documentos. La pantalla sólo demuestra una representación producida por el cliente. Para afirmar que la cuenta fue autenticada se necesita evidencia del servicio; para afirmar que un documento puede editarse se necesita una decisión de autorización distinta.
Login no es autorización total
El login puede establecer un principal para una sesión, pero cada recurso y acción puede tener una regla distinta. Una cuenta autenticada puede leer un documento público y no modificar uno privado. La palabra «entró» no resuelve la política.
Permisos por recurso
Un permiso debe nombrar sujeto, acción, recurso y condición. «Puede usar la biblioteca» es demasiado amplio. «El principal P puede leer el documento D durante la sesión S» permite preguntar qué evidencia sostiene cada componente.
Desliza horizontalmente para leer el diagrama a tamaño completo.
Sesiones paralelas
Una cuenta puede tener una sesión en un navegador y otra en un teléfono. Cerrar una interfaz puede eliminar sólo una representación local. La conclusión sobre terminación debe indicar qué sesión y qué evidencia se observaron.
Desliza horizontalmente para leer el diagrama a tamaño completo.
Cambio de estado
La autenticación, la autorización y la sesión cambian con eventos distintos. Una credencial aceptada puede crear contexto; una política puede negar una acción; una expiración puede terminar una sesión sin borrar la cuenta.
Observaciones e inferencias
Una pantalla con el nombre de Alex es una observación de interfaz. «Alex es quien controla la cuenta» es una inferencia. «El principal fue autenticado para leer D» es un claim más estrecho que necesita operación, servicio y momento.
Recuperación y cuenta
Un proceso de recuperación puede modificar una credencial o devolver acceso, pero no prueba por sí solo que una sesión antigua haya terminado. El modelo debe distinguir cuenta, credencial nueva, sesiones previas y políticas de invalidación.
Desliza horizontalmente para leer el diagrama a tamaño completo.
Contexto y condiciones
Una decisión de autorización puede depender de recurso, acción, sesión, hora, estado de cuenta o relación con una organización. No se deben convertir permisos de un contexto en garantías globales.
Revisión de hipótesis
Si una acción permitida falla, las hipótesis incluyen principal distinto, sesión expirada, permiso ausente o recurso diferente. Cada hipótesis exige una observación situada. No basta repetir que «el usuario inició sesión».
Caso negativo
Si Alex cierra el navegador y una actividad continúa en otro dispositivo, la observación contradice la hipótesis de cierre global. El resultado obliga a distinguir interfaz local y sesiones restantes, no a inventar un mecanismo específico.
Transferencia
El mapa sirve para una cuenta de aprendizaje, una consola administrativa o una biblioteca. Cambian recursos y políticas; se conservan sujeto, principal, credencial, autenticación, autorización, permiso y sesión.
Límites
No se desarrollan contraseñas, MFA, tokens, OAuth, Kerberos ni modelos profundos de identidad. El objetivo es localizar preguntas y separar términos antes de estudiar mecanismos especializados.
Cierre
Una explicación competente identifica quién, qué cuenta, qué principal, qué evidencia, qué acción, qué recurso, qué sesión y qué condición. Si falta una pieza, reduce el alcance del claim.
Fuentes principales
- NIST CSRC Glossary — authentication, authorization, account, credential, identity y session.
- NIST SP 800-63-4 — términos y niveles de identidad digital; aquí sólo se usa como vocabulario.
- RFC 9110 — roles de interacción cliente/servidor.
Reconstruir una interacción sin confundir sus capas
La persona que creó una cuenta puede no ser quien opera una sesión concreta. Una cuenta de equipo, una delegación o una estación compartida obligan a preguntar qué principal reconoció el servicio y mediante qué relación. Que una credencial sea aceptada sólo demuestra una decisión del autenticador en ese contexto: no establece todas las propiedades de la persona ni anticipa todos sus permisos.
La autorización evalúa una solicitud situada. Conviene escribirla como una tupla: principal, acción, recurso, condiciones y decisión. «Alex puede usar la biblioteca» mezcla demasiadas cosas; «en la sesión S, el principal P recibió permiso para leer el documento D» conserva los límites. La misma sesión podría recibir una denegación al intentar editar D o leer otro documento.
Seguir el tiempo: sesión, cierre y revocación
Una sesión tiene historia. Se crea o reconoce, conserva cierto contexto entre interacciones y puede expirar o ser revocada. El horizonte no se deduce de que una pantalla siga abierta. Tampoco se deduce el final global de que una ventana desaparezca: cerrar una interfaz, cerrar la sesión actual, revocar todas las sesiones y eliminar la cuenta son cuatro cambios diferentes.
Supongamos que Alex usa la biblioteca desde un navegador y un teléfono. Al cerrar el navegador sólo observamos que esa interfaz dejó de mostrarse. Si el teléfono continúa accediendo, queda refutada la hipótesis de que todas las sesiones terminaron. Todavía no sabemos si el navegador destruyó su sesión, perdió su copia local o simplemente cerró la vista; para saberlo haría falta observar el servicio o probar de forma autorizada la continuidad de esa sesión concreta.
Recuperar acceso no restablece mágicamente todo el sistema
La recuperación modifica la relación de acceso a una cuenta mediante un flujo excepcional. Puede permitir registrar o sustituir una credencial, pero de ese resultado no se sigue que las sesiones anteriores hayan sido revocadas, que los permisos hayan cambiado ni que la identidad humana haya quedado demostrada con un alcance mayor. Cada una de esas conclusiones necesita evidencia propia.
Este límite importa porque el diseño de recuperación suele conectar componentes que el uso normal mantiene separados: cuenta, métodos de contacto, credenciales y sesiones. Un modelo claro muestra qué objeto cambia y cuáles quedan sin determinar. Si el servicio anuncia «cerramos las demás sesiones», esa frase es una afirmación verificable sobre el servicio, no una consecuencia lógica de haber recuperado la cuenta.
De la pantalla a una afirmación defendible
Una pantalla con el nombre de Alex es evidencia producida por un cliente. Puede corresponder a la sesión esperada, a otra cuenta, a datos conservados localmente o a una vista desactualizada. Para discriminar esas explicaciones hay que buscar observaciones que no predigan lo mismo: el recurso solicitado, la respuesta del servicio, el principal efectivo, el instante y el alcance de la sesión.
Desliza horizontalmente para leer el diagrama a tamaño completo.
Una afirmación bien limitada podría ser: «A las 10:32, en la sesión S del servicio B, el principal P recibió permiso para leer el recurso R». No afirma que P sea una persona concreta, que pueda editar R ni que otra sesión tenga el mismo estado. Cuanto menos observemos, más estrecho debe ser el enunciado.
Método de diagnóstico inicial
Ante un acceso inesperado, conviene recorrer estas preguntas en orden:
- ¿Qué interfaz y qué servicio produjeron la observación?
- ¿Qué cuenta y qué principal aparecen implicados? ¿Sabemos realmente quién opera la sesión?
- ¿Qué evidencia fue evaluada y qué resultado de autenticación se observó?
- ¿Cuál era la acción, el recurso y la condición de la solicitud?
- ¿Qué sesión recibió la decisión y qué otras sesiones podrían existir?
- ¿Qué cambió de forma observable: la interfaz, una sesión, todas las sesiones, una credencial o la cuenta?
El orden evita que «estaba logueado» se convierta en explicación universal. También permite formular rivales comprobables: principal distinto, sesión expirada, recurso diferente, permiso ausente o política contextual. Una prueba útil varía una dimensión autorizada y conserva el resto; no explora datos ajenos ni convierte una conjetura en hecho.
Tres recorridos completos
El vocabulario se vuelve útil cuando permite contar una historia sin saltos. Consideremos primero una cuenta individual. Alex presenta una credencial a la biblioteca. El autenticador la evalúa y el servicio reconoce al principal P-17 dentro de la sesión S-web. Alex solicita leer el documento A; la política evalúa esa acción y devuelve permitido. Después solicita editar A y recibe denegado. La identidad, la autenticación y la sesión permanecen iguales entre ambas solicitudes. Lo que cambió fue la acción evaluada. Por tanto, la diferencia entre resultados no prueba un fallo de login: muestra que la autorización no era idéntica para leer y editar.
Ahora consideremos una cuenta de equipo. En una pantalla aparece el nombre «Archivo nocturno». El nombre identifica una cuenta o una etiqueta dentro del servicio, no a la persona que está delante del monitor. Si dos operadores conocen una forma legítima de acceso compartido, el servicio puede reconocer el mismo principal en momentos distintos. El registro de cuenta puede permitir atribuir la operación a ese principal, pero no necesariamente discriminar al operador humano. Resolver esa atribución exigiría otro diseño y otras evidencias. Cambiar el nombre mostrado por un nombre personal no arreglaría el problema: sólo haría más convincente una inferencia que el sistema todavía no sostiene.
El tercer recorrido comienza con pérdida de acceso. Alex ya no controla la credencial habitual y activa recuperación. El servicio evalúa evidencia de recuperación y permite asociar una credencial nueva a la cuenta. En ese momento sabemos que el flujo produjo un nuevo vínculo de acceso. No sabemos todavía qué ocurrió con S-web, con la sesión del teléfono ni con los permisos sobre A. Si la política de recuperación ordena revocar todas las sesiones y el servicio registra esa transición, podremos añadirlo al relato. Sin ese evento, dibujar las sesiones antiguas como terminadas sería completar el modelo con una suposición.
Los tres recorridos comparten estructura, pero no resultado. En el primero, autenticación constante convive con dos decisiones de autorización. En el segundo, el principal técnico no resuelve la atribución humana. En el tercero, recuperar una credencial no determina por lógica el estado de las sesiones. Esta comparación enseña una disciplina básica: cuando un término parece explicar demasiado, hay que volver a las entidades y a los cambios observados.
Estados que conviene registrar por separado
Para razonar sobre una interacción no hace falta conocer todavía el protocolo interno, pero sí evitar un único indicador llamado «conectado». Un registro conceptual mínimo puede mantener cinco columnas: estado de cuenta, credencial evaluada, resultado de autenticación, sesión y decisión de autorización. Cada columna responde a una pregunta distinta y puede cambiar sin que todas las demás cambien.
La cuenta puede estar habilitada o suspendida. Una credencial puede estar registrada, sustituida o dejar de ser aceptada. Una autenticación puede tener éxito o fallar en un instante. Una sesión puede estar activa, expirada o revocada. Una solicitud puede quedar permitida o denegada para cierta acción y recurso. Estos valores no forman una escalera automática. Por ejemplo, autenticación aceptada no obliga a que una solicitud se permita; una solicitud denegada no implica que la cuenta esté suspendida; una sesión expirada no elimina la cuenta; una credencial sustituida no demuestra por sí sola que todas las sesiones anteriores hayan desaparecido.
También importa quién produce cada dato. El cliente presenta una pantalla; el servicio procesa una solicitud; el autenticador decide sobre evidencia; el componente de política decide sobre una acción; el almacén de cuenta conserva relaciones administrativas. En una implementación real esas funciones pueden residir en el mismo programa o distribuirse entre varios, pero la separación conceptual sigue siendo útil. Permite preguntar qué componente está en posición de sostener una afirmación y qué información sólo repite de otro.
Una tabla de estados no es la realidad completa. Es un modelo para detectar contradicciones y vacíos. Si la pantalla dice «sesión cerrada» mientras el servicio acepta una nueva solicitud bajo S-web, ambas observaciones necesitan reconciliarse: quizá la etiqueta describía la interfaz, otra sesión o un evento pendiente. El método no elige de inmediato una causa; impide que una sola observación silencie las demás.
Alcance de la autorización
Una decisión de autorización siempre tiene alcance, aunque la interfaz lo oculte. El principal P-17 puede recibir permiso para leer A bajo una condición C, durante una sesión S y en un momento T. Cambiar cualquiera de esos elementos crea una pregunta nueva. Leer B no es leer A; compartir A no es leer A; actuar mañana no es necesariamente actuar hoy; una sesión móvil no es la sesión web.
Esta precisión evita dos extremos. El primero es imaginar un permiso universal: «Alex tiene acceso». El segundo es describir cada decisión con tanto detalle que el modelo deje de ser manejable. La solución es conservar las dimensiones que pueden cambiar el resultado. Si la biblioteca trata igual todos los documentos públicos, puede modelarlos como una clase de recursos. Si distingue cada documento privado por propietario, esa relación debe aparecer. El nivel de detalle se justifica por la decisión que intentamos explicar.
La denegación merece el mismo cuidado. Una pantalla que muestra «sin permiso» comunica un resultado, pero no necesariamente la regla exacta que lo produjo. Podría faltar una relación con el recurso, haber expirado la sesión o existir una condición adicional. En una investigación autorizada se comparan solicitudes y estados conocidos; no se adivina la política a partir de un mensaje genérico. El enunciado inicial puede ser simplemente: «la interfaz informó una denegación para esta solicitud». Sólo una fuente adicional permite convertirlo en «la política denegó porque faltaba el permiso X».
Sesiones como continuidad limitada
La sesión permite que varias interacciones se interpreten dentro de cierta continuidad. Esa continuidad no es una persona, una cuenta ni una credencial: es estado asociado a interacciones posteriores a una autenticación o a otro evento definido por el servicio. Puede llevar un identificador, un límite temporal y condiciones para continuar, pero esos detalles pertenecen al diseño concreto.
Dos sesiones del mismo principal pueden divergir. Una puede expirar por inactividad mientras la otra continúa; una puede revocarse de forma selectiva; una puede haber sido creada antes de un cambio de credencial. El simple hecho de compartir cuenta no las convierte en una única entidad. Por eso, cuando la biblioteca muestra «dispositivos conectados», cada entrada debería interpretarse como una representación de cierto estado de sesión, no como prueba infalible de una persona físicamente presente.
Cerrar sesión también necesita objeto. «Cerrar esta sesión» apunta a una entidad; «cerrar todas las sesiones» apunta a un conjunto definido por el servicio. «Cerrar el navegador» describe un evento del cliente. «Eliminar la cuenta» modifica o termina una relación administrativa mucho más amplia. Si una interfaz usa el mismo verbo para varios efectos, el lector debe buscar la descripción de alcance y observar el resultado antes de equipararlos.
Recuperación como frontera de confianza
La recuperación existe porque el servicio admite que el camino ordinario de autenticación puede dejar de estar disponible. Por eso no debe analizarse como un botón auxiliar sin consecuencias: introduce evidencia, actores y canales distintos. En este capítulo no estudiamos sus mecanismos, pero sí una pregunta previa decisiva: ¿qué relación se intenta restablecer y qué cambios promete el servicio al completarla?
Un flujo podría permitir vincular una credencial nueva, notificar al titular y revocar sesiones. Otro podría sólo devolver acceso y dejar la revisión de sesiones como una acción separada. Ambos caben en el concepto general de recuperación, pero producen estados finales distintos. La documentación y las observaciones del servicio determinan cuál aplica. El lector no debe importar garantías de un sistema a otro sólo porque ambos usan la palabra «recuperar».
También conviene separar éxito de legitimidad. Que el servicio complete el flujo prueba que sus condiciones fueron satisfechas; no garantiza por sí solo que la persona legítima lo inició. Esa evaluación requiere el modelo de amenazas y los mecanismos que aparecerán en capítulos posteriores. Aquí basta con conservar la diferencia entre «el servicio aceptó la recuperación» y «sabemos quién estaba detrás de ella».
Errores de lenguaje que anticipan errores de seguridad
Las frases imprecisas no son sólo un problema estilístico. «El usuario es la cuenta» borra delegaciones y cuentas compartidas. «La contraseña identifica a Alex» confunde una credencial con una persona. «Entró, así que puede hacerlo» elimina la autorización. «Cerró la ventana, así que salió» confunde interfaz con sesión. «Recuperó la cuenta, así que todo quedó seguro» oculta sesiones previas y condiciones adicionales.
Una redacción más rigurosa no necesita sonar burocrática. Puede decir: «la biblioteca aceptó la credencial y reconoció al principal P en la sesión S»; «la solicitud para leer A fue permitida»; «la interfaz local se cerró, pero el estado de S no fue observado»; «la recuperación vinculó una credencial nueva y no sabemos aún qué sesiones fueron revocadas». Cada frase es más larga que el atajo, pero también indica exactamente qué evidencia faltaría para afirmar más.
Esta disciplina prepara el resto de la obra. Más adelante aparecerán contraseñas, factores, tokens, directorios, protocolos y políticas. Sin este mapa, esos mecanismos se convierten en una lista de siglas. Con él, cada mecanismo ocupa un lugar: presenta evidencia, mantiene continuidad, transporta una afirmación o decide una solicitud. El objetivo de esta parte cero no es resolver todos esos mecanismos, sino dar al lector preguntas estables para estudiarlos sin confundir sus funciones.
Comprobación
Reconstruye el caso de Alex sin limitarte a enumerar términos. Debes identificar sujeto, cuenta, principal, credencial, decisión de autenticación, acción, recurso, condiciones, sesión y evidencia observada. Después explica qué seguiría siendo desconocido si sólo vieras el nombre de Alex en pantalla y qué observación adicional distinguiría entre una sesión local cerrada y una revocación global.