Autenticación

Un club de lectura ficticio permite a Maya entrar, mantener la sesión mientras navega y editar sus reseñas. Son tres decisiones: establecer un contexto de cuenta, mantenerlo y comprobar permiso para una acción. Separarlas ayuda a comprender diseños correctos y errores frecuentes.

Una cuenta no equivale a una identidad civil

La Autenticación establece confianza en el control del autenticador esperado: contraseña, llave de seguridad o credencial ligada a un dispositivo. No demuestra necesariamente un nombre legal. Una cuenta con seudónimo puede autenticarse correctamente.

La autorización pregunta algo distinto: ¿puede esta cuenta editar esta reseña ahora? El contenido público puede admitir lectura anónima; editar exige cuenta autenticada y comprobar propiedad. Una autenticación fuerte no repara autorización ausente.

Recordar el acceso de forma segura

Una Sesión vincula interacciones posteriores al contexto autenticado. Una cookie opaca puede transportar un identificador aleatorio mientras el servidor guarda el estado. Las cookies son un mecanismo de entrega del navegador, no contraseñas, firmas o registros de identidad por naturaleza.

El navegador envía una cookie cuando sus reglas de coincidencia y seguridad lo permiten. Secure, HttpOnly y SameSite responden a riesgos distintos; no eliminan caducidad, protección de solicitudes ni comprobaciones del servidor. Cerrar sesión debe terminar la sesión prevista; recuperar la cuenta puede exigir revocar otras también.

Maya cambia su contraseña. ¿Salen todos sus dispositivos?

Depende de la política de sesiones. Cambiar contraseña no invalida necesariamente cada sesión o token existente. El diseño debe definir e implementar qué sigue válido, y la interfaz debe describirlo con precisión.

Credenciales distintas, comprobaciones distintas

HTTP Basic envía credenciales codificadas en una cabecera de autorización. Base64 no cifra; HTTPS protege el transporte. Un Token portador se acepta por posesión dentro de sus condiciones. Puede ser opaco o usar JWT. JWT es un formato, no garantía de seguridad ni cifrado. El receptor valida emisor, destinatario, duración y permisos aplicables.

OAuth se ocupa principalmente de autorización delegada. OpenID Connect añade autenticación. Un token de acceso y uno de identidad tienen destinatarios y funciones diferentes: no son pruebas de acceso intercambiables.

Centralizar la prueba no centraliza cada decisión

El Inicio de sesión único permite confiar en un proveedor de identidad y validar sus afirmaciones. Cada aplicación puede crear su sesión y aplicar políticas propias. La gestión centralizada ayuda, pero fallos del proveedor, recuperación y sesiones antiguas requieren planificación.

El TLS mutuo puede autenticar ambos extremos mediante certificados y pruebas de sus claves privadas. Las claves no se transmiten. El certificado identifica al extremo según la configuración de confianza; no permite automáticamente todas las acciones de la aplicación.

Elige mecanismos según garantías, facilidad de uso y ciclo de vida necesarios. Sigue con ciclos de sesión y autorización de objetos para ir más allá del inicio de sesión.

Sigue una solicitud al cruzar el límite

Maya abre una reseña guardada. Su navegador entrega el identificador de sesión; el servicio encuentra una sesión vigente asociada a su cuenta. Eso responde qué contexto de cuenta corresponde. Después, la aplicación compara la cuenta con el propietario de la reseña y comprueba la acción solicitada. Son dos preguntas distintas aunque una biblioteca implemente partes de ambas.

El club concede a Maya el rol de editora de eventos. Puede actualizar descripciones de reuniones, pero no necesita acceso a pagos ni a borradores privados ajenos. Una regla útil incluye sujeto, acción, recurso y contexto pertinente. “Ha iniciado sesión” es una condición, no toda la regla de acceso.

Cuando Maya deja de colaborar, se retira el rol. Una pantalla antigua puede seguir mostrando Editar. Esa presentación desactualizada no debe decidir la siguiente solicitud. La aplicación necesita una política para evaluar permisos actuales y tratar atributos almacenados en caché o tokens emitidos anteriormente. El efecto depende de duración y revocación, por lo que la interfaz no debería prometer un cambio universal inmediato si el sistema no lo proporciona realmente.

PrediceEl proveedor de identidad cierra la sesión de Maya. ¿Terminan necesariamente todas sus sesiones abiertas en otras aplicaciones?

No. Las aplicaciones pueden mantener sesiones y mecanismos de terminación propios. El sistema necesita acuerdos explícitos para el cierre o la revocación deseados. Cerrar correctamente en el proveedor no describe por sí solo lo ocurrido en cada aplicación que confía en él.

Piensa en cambios de estado: vincular un autenticador, demostrar control, crear sesión, evaluar solicitudes y después caducar o revocar el estado correspondiente. Recuperar una cuenta puede cambiar varios estados y merece el mismo cuidado que entrar normalmente. Anotar qué estado cambia evita confundir una operación de la interfaz con una garantía del servicio.

Explora identidad, credenciales y sesiones para seguir el ciclo y autenticación y autorización para las decisiones sobre recursos concretos.