Autenticación y acceso

Saber quién inició sesión es el comienzo de una decisión de acceso. Una clínica también debe decidir si esa persona puede leer esta cita, modificar este registro o administrar el servicio. La misma identidad puede tener permiso para una acción y no para otra.

Objetos, acciones y relaciones

La autorización de objetos controla acceso a un registro concreto. La de funciones controla una operación o capacidad. La política puede depender de rol, propiedad, organización, delegación o relación asistencial. Los identificadores difíciles de adivinar reducen descubrimiento, pero no sustituyen permisos.

Aplica las reglas en el servidor en cada operación relevante. Vistas de lectura, lotes, exportaciones y tareas de fondo merecen tanta atención como los botones de edición.

Las sesiones mantienen autoridad

Una sesión relaciona solicitudes posteriores con una autenticación anterior. Renueva identificadores al autenticar y en cambios de privilegios relevantes para reducir fijación. Aplica caducidad y revocación apropiadas. Los atributos de cookies añaden protección del navegador, pero no deciden acceso a registros.

No uses una IP o conexión TLS como identidad universal de sesión: las redes móviles cambian, existen intermediarios y se reemplazan conexiones. Las señales de contexto ayudan a valorar riesgo, pero también pueden dificultar el uso legítimo.

Escenario: el emisor externo de la clínica

La clínica acepta JWT de su proveedor confiable. Verifica la protección criptográfica con algoritmos y claves expresamente permitidos, y comprueba emisor, destinatario previsto, vigencia y propósito. Las declaraciones pueden proceder de un emisor externo confiable; la clínica no necesita emitir todos sus tokens.

Las declaraciones validadas orientan la autorización, pero significado y actualización deben ajustarse a la aplicación. Al retirar un rol, hace falta una estrategia adecuada de revocación, duración corta o comprobación de política vigente. Consultar la base de datos en cada solicitud es una opción, no una obligación universal de JWT. RFC 8725 explica problemas de validación.

La recuperación también autentica

Los tokens de recuperación necesitan imprevisibilidad suficiente, duración limitada, uso único cuando corresponda y protección frente a divulgación. Cambiar autenticadores o direcciones de recuperación debe seguir reglas explícitas de garantía y notificación.

MFA mejora los flujos que cubre. No evita cualquier phishing, uso de sesiones robadas o debilidad de recuperación. Limitar y vigilar intentos en línea ayuda frente a repeticiones; el bloqueo permanente puede negar acceso a usuarios legítimos.

Una revisión útil documenta actor, recurso, acción y evidencia de identidad usados por el servidor, separando fallos confirmados de información de diseño ausente.

Revisión resuelta: token válido con un rol desactualizado

Un JWT es un formato de token que contiene declaraciones; poder leerlas no las convierte en entradas fiables sin la validación requerida. La clínica ficticia utiliza tokens de acceso firmados y estos registros:

A1, política: El personal clínico solo lee citas asignadas. Retirar ese rol debe impedir nuevas lecturas en un máximo de dos minutos. Dani tiene asignada A17, no B42.

A2, antes de retirarlo: La API valida el token de Dani para la audiencia ClinicAppointments. Permite leer A17 y deniega B42.

A3, después: A las 12:00 se retira el rol. La firma se valida y el token caduca a las 12:30. A las 12:04, la API acepta la declaración antigua y devuelve A17. Las horas comparten reloj.

A4, caso separado: Otro token firmado por el mismo emisor está destinado solo a StaffPortal. ClinicAppointments no es una audiencia aceptada para ese token y no existe un acuerdo de intercambio de tokens.

Predice¿La firma válida y la caducidad futura hacen correcta la lectura de A3 a las 12:04?

No. La firma no establece que el rol siga cumpliendo la política vigente de autorización. Ya pasaron los dos minutos de A1. El hallazgo es autoridad desactualizada aceptada para esa lectura, no un algoritmo de firma roto.

Elige un ciclo que cumpla el requisito

Responsable y equipo necesitan un diseño cuyo retraso sea compatible con dos minutos. Pueden contribuir una comprobación actual de autorización, caché acotada, revocación o duración adecuadamente limitada de tokens y sesiones. Depender solo de que este token caduque a las 12:30 no cumple A1.

Hay compromisos: consultar estado actual introduce una dependencia; una caché necesita límite de antigüedad y conducta ante fallos explícitos. Retirar el rol solo de la pantalla cambia presentación, no la decisión del servidor. Documenta también la vía usada por tareas de fondo y exportaciones.

A4 debe rechazarse para esta API pese al emisor fiable y la firma válida. La audiencia establece dónde se pretende usar el token. A2 es distinto: el token se valida y después la política del objeto deniega correctamente B42.

La aceptación demuestra que Dani pierde lectura dentro del plazo, otra persona autorizada conserva sus citas y siguen denegadas las ajenas. Registra qué token, sesión y operación se evaluaron sin conservar credenciales reales. Verifica así el límite concreto sin afirmar que MFA o un inicio correcto cubran toda recuperación y sesión.