Autenticación y autorización

Maya entra correctamente en un club de lectura ficticio. Puede editar su reseña, leer las publicadas y consultar la siguiente reunión. No puede cambiar los datos de pago del club. No hay contradicción: el servicio puede confiar en el contexto de su cuenta y, aun así, denegar una operación.

Formula una pregunta completa

La autenticación pregunta si alguien ha demostrado control del autenticador o cuenta esperado. La autorización pregunta si un sujeto puede realizar una acción sobre un recurso bajo las condiciones actuales. “Maya tiene permiso” está incompleto. “Maya puede editar la reseña que posee mientras su membresía esté activa” resulta mucho más útil.

El sujeto puede ser una persona, una aplicación o un trabajo automático. El recurso puede ser un registro, archivo, reserva o ajuste administrativo. El contexto puede incluir relación con ese recurso, rol actual o necesidad de autenticación reciente. Nombrar cada parte hace visibles los supuestos que faltan.

Los roles son un comienzo

Un rol agrupa permisos para una clase de trabajo. El editor actualiza descripciones de reuniones; el tesorero gestiona registros de pago. El rol de socio no explica por sí solo qué reseñas puede cambiar cada persona. La propiedad u otra relación pueden formar parte de la regla.

Del mismo modo, un rol en un grupo no debe conceder silenciosamente ese rol en todos los grupos del servicio. La organización o espacio de trabajo pertenece al contexto de la decisión. Por eso un acceso correcto no puede sustituir todas las comprobaciones posteriores.

La interfaz no tiene la autoridad

Ocultar un botón facilita el uso de una pantalla, pero el servicio debe aplicar su regla cuando recibe una solicitud protegida. Una misma operación puede estar disponible desde otras pantallas o una interfaz de aplicación. Cada vía admitida necesita las comprobaciones apropiadas.

Esto no significa que quien empieza deba inventar su propio motor de permisos. Significa que el diseño debe expresar reglas explícitas, utilizar mecanismos mantenidos y verificar tanto casos permitidos como denegados con registros ficticios en su entorno de desarrollo.

PrediceSe retira a Maya el rol de editora, pero una pestaña antigua sigue mostrando Editar. ¿Debe conservar el permiso gracias a esa pestaña?

No. La pantalla puede estar desactualizada. El servicio debe aplicar la política vigente pertinente al procesar la operación. El tiempo que tardan roles en caché o tokens emitidos en reflejar cambios forma parte del diseño y debe considerarse.

Los cambios importan tanto como entrar

Los permisos pueden cambiar durante una sesión. Una membresía termina, un documento cambia de propietario o una operación sensible exige pruebas más fuertes. La sesión válida y la decisión de permiso vigente son comprobaciones distintas. Cierre de sesión, retirada de rol y caducidad de token también significan cosas distintas; ninguno sustituye universalmente a los demás.

Haz concreta la revisión del club: el socio edita su reseña, el editor actualiza reuniones y el tesorero modifica pagos después de las comprobaciones necesarias. Después pregunta por una reseña ajena, un rol retirado y otro club. Una buena explicación indica por qué se permite o deniega cada solicitud.