Autenticación vs autorización

Cada solicitud que hace un usuario plantea dos preguntas, y se responden en orden.

¿Quién es esta persona? y ¿qué puede hacer?

La primera es autenticación. La segunda es autorización. Ambas se abrevian como "auth", ambas empiezan con las mismas letras, y resuelven problemas completamente distintos.

Demostrar quién eres

La autenticación responde una sola pregunta: ¿esta persona es realmente quien dice ser?

Ya conoces los métodos comunes como usuario:

• Un nombre de usuario y contraseña.
• Iniciar sesión con Google o GitHub.
• Enviar una API key o un token junto con la solicitud.

Cada uno es una forma de presentar evidencia. El trabajo del servidor es decidir si esa evidencia es válida.

Si esto falla, alguien puede hacerse pasar por otra persona. Eso es suplantación, la S de STRIDE, y es el fallo que vuelve irrelevante cualquier otra protección, porque la aplicación termina aplicando las reglas correctas a la persona equivocada.

JunoDemostrar quién eres Ayuda pensar en la autenticación como la puerta, y en todo lo que viene después como lo que puedes tocar una vez que estás dentro.

A la puerta no le importa qué quieres hacer. Su único trabajo es decidir si eres quien dices ser.

JunoDemostrar quién eres Vale la pena entender bien los códigos de estado, porque sus nombres confunden. Un 401 se llama Unauthorized pero en realidad significa "no autenticado": no sabemos quién eres, así que inicia sesión. Un 403 es Forbidden y significa que sabemos exactamente quién eres y aun así no puedes hacer esto.

Enviar un 403 cuando el usuario no tiene sesión le dice al cliente que se rinda, cuando lo correcto era pedirle que inicie sesión.

JunoDemostrar quién eres La distinción clave es que la autenticación ocurre una vez por sesión y produce una afirmación de identidad, mientras que la autorización ocurre en cada solicitud y consume esa afirmación. La mayoría de los bugs de identidad tienen que ver con cuánto tiempo se sigue confiando en esa afirmación después de que los hechos que la sustentan cambiaron.

Vale la pena separar un tercer término que suele mezclarse. La identificación es presentar una afirmación, la autenticación es demostrarla, y la rendición de cuentas (accountability) es poder mostrar después quién hizo qué.

STRIDE le da al repudio su propia letra precisamente porque un sistema puede autenticar correctamente y aun así ser incapaz de demostrar después quién realizó una acción.

Decidir qué puedes hacer

La autorización se ejecuta después, y solo tiene sentido una vez resuelta la identidad:

• Un usuario que lee sus propios datos.
• Un usuario que actualiza su propio perfil.
• Un profesor que consulta los registros de sus estudiantes.
• Esa misma solicitud hecha por un estudiante, rechazada.

Si esto falla, la gente hace cosas que no debería. En STRIDE eso es elevación de privilegios; en el OWASP Top 10 es control de acceso roto, que lleva años en el primer lugar de la lista.

JunoDecidir qué puedes hacer Fíjate en que la misma persona recibe respuestas distintas según lo que esté pidiendo.

Estar conectado no es un permiso único. Es el punto de partida de una pregunta distinta que se hace de cero en cada solicitud.

JunoDecidir qué puedes hacer El error común es verificar solo si alguien inició sesión y quedarse ahí. Una ruta que carga un registro por id y lo devuelve a cualquier usuario autenticado tiene autenticación, pero ninguna autorización.

La pregunta que hay que hacerle a cada handler que recibe un id es: ¿confirma que este usuario es dueño de este registro? Cuando la respuesta es no, esa brecha tiene nombre propio: una referencia directa insegura a objetos, y es la forma más común que toma el control de acceso roto.

JunoDecidir qué puedes hacer Dónde vive la decisión importa más que cómo se expresa. Las verificaciones dispersas por los handlers se van desalineando con el tiempo, y la única ruta que se olvidó de hacerlas queda invisible hasta que alguien la encuentra.

Los patrones que funcionan bien centralizan la decisión: una capa de políticas a la que la ruta consulta, o una capa de datos que no puede devolver filas sobre las que quien llama no tiene ningún derecho. Ambos enfoques permiten responder "qué endpoints verifican propiedad" leyendo un solo lugar.

Un botón oculto no es autorización. Es una cortesía para los usuarios honestos, exactamente igual que la validación en el navegador, y la ruta detrás de ese botón sigue respondiendo a cualquiera que la llame directamente.

El orden en que se ejecutan

Toda solicitud que llega a un recurso protegido pasa por ambas etapas, siempre en la misma secuencia:

solicitud  ──▶  autenticación  ──▶  autorización  ──▶  recurso
                (¿quién eres?)      (¿puedes hacer esto?)

Dos ejemplos aclaran el patrón. Un usuario que lee su propio perfil: llega la solicitud, la autenticación establece quién es, la autorización confirma que el perfil le pertenece, y se concede el acceso.

Un administrador que accede a un endpoint exclusivo para administradores: llega la solicitud, la autenticación establece quién es, la autorización verifica los permisos de administrador, y se concede el acceso.

Solo uno de los cuatro pasos cambia entre esos dos casos. La verificación de identidad es idéntica, y es en la verificación de permisos donde las dos solicitudes se separan.

Una autenticación fuerte con una autorización débil no es segura. Una autorización fuerte sin una autenticación sólida no tiene sentido.

JunoEl orden en que se ejecutan El orden no es una convención, es una dependencia. No puedes decidir qué puede hacer alguien hasta que sabes quién es.

Por eso la autenticación siempre va primero, y por eso un error ahí arruina todo lo que viene después.

JunoEl orden en que se ejecutan En una app de Express, ambos pasos son middleware, y el orden en la cadena es el orden del diagrama. Una verificación de autorización colocada antes que la de autenticación se ejecuta contra un usuario que todavía no ha sido identificado.

El orden del middleware es una cuestión de comportamiento, no solo de prolijidad, algo que vale la pena recordar cuando una ruta deja de funcionar después de que alguien reordena su definición.

JunoEl orden en que se ejecutan Presta atención a las decisiones de autorización que se toman contra una identidad desactualizada. Una sesión o token estableció la afirmación de identidad al iniciar sesión, y el rol asociado a ella puede estar desactualizado por minutos u horas para cuando llega una solicitud.

Si esa brecha es aceptable o no es la disyuntiva que subyace a todo modelo de identidad de esta sección. Las sesiones guardadas en el servidor pueden actualizarse o destruirse al instante. Los tokens autocontenidos no, y por eso el token de un empleado despedido sigue funcionando hasta que expira.

Eso es una decisión de diseño, no un detalle de implementación, y por eso los próximos capítulos tratan sobre dónde vive la identidad.

Ponlo a prueba

Cuatro situaciones. Para cada una, decide si la falla es de autenticación o de autorización, y nombra la letra de STRIDE que le corresponde.

1. Un formulario de inicio de sesión acepta cualquier contraseña para el usuario admin.
2. Un cliente con sesión iniciada cambia el id en una URL y ve el pedido de otro cliente.
3. Un endpoint de API acepta solicitudes sin ningún token.
4. Un agente de soporte puede eliminar cuentas, algo que solo debería ser posible para administradores.

Compara tus respuestas

#	Falla	Por qué	STRIDE
1	Autenticación	La app no puede saber quién está frente al teclado, así que cualquiera puede hacerse pasar por admin	Suplantación
2	Autorización	El cliente realmente es quien dice ser; nunca se verificó si el pedido le pertenece	Elevación de privilegios
3	Autenticación	No se presenta ninguna afirmación de identidad, así que el endpoint no tiene forma de saber quién llama. Un 401 es la respuesta correcta	Suplantación
4	Autorización	El agente está correctamente identificado y lo que falla es la verificación de permisos. Un 403 es el rechazo correcto	Elevación de privilegios

El número 2 tiene nombre propio: una referencia directa insegura a objetos. En términos de OWASP, tanto el 2 como el 4 son control de acceso roto.

El dos y el cuatro son el mismo tipo de bug con distinto disfraz, y esa es parte de la razón por la que el control de acceso roto se mantiene en el primer lugar de la lista de OWASP. En ambas apps se sabía exactamente quién estaba pidiendo qué.

Hacia dónde vamos ahora

La autenticación ocurre una vez, al iniciar sesión. La autorización ocurre en cada solicitud posterior, y necesita saber quién es el usuario cada vez.

Eso deja una brecha incómoda, porque HTTP no recuerda nada de una solicitud a la siguiente.

Cómo las apps te recuerdan es el problema que crea esa brecha, y las tres familias de soluciones que veremos en el resto de esta sección.