Autenticación vs. Autorización: ¿cuál es la diferencia?

La autenticación es la verificación de quién eres; la autorización es la decisión de qué puedes hacer en cada solicitud. Todo sistema seguro necesita ambas. El hotel lo hace concreto: tu identificación en la recepción es autenticación; la tarjeta que abre la habitación 412 — y solo la 412 — es autorización. Son preguntas distintas, formuladas en momentos distintos, respondidas por maquinaria distinta, y fallan de maneras distintas — por eso los sistemas que las difuminan terminan sufriendo ambos tipos de brecha.

Puntos clave

Cómo corren la autenticación y la autorización en una misma solicitud

1  POST /login  (credenciales + MFA)         ── AUTENTICACIÓN, una vez
   ← token de sesión / cookie: identidad establecida

2  GET /documents/xKd91m                     ── cada solicitud posterior:
   a · token validado       → identidad re-establecida            (maquinaria authn)
   b · permiso evaluado     → ¿puede ADA leer ESTE documento?     (decisión authz)

   → 200  ambas pasaron
   → 401  token ausente/inválido — desafío WWW-Authenticate; iniciar sesión lo arregla
   → 403  token válido, permiso denegado — volver a iniciar sesión no cambia nada
   → 404  algunas APIs ocultan por completo los objetos prohibidos (RFC 9110 lo permite)

La misma división en el código de la aplicación — inicias sesión una vez y te juzgan por operación:

// JavaScript / Node.js — Back4app JS SDK
// Authentication: once — who are you?
const user = await Parse.User.logIn('ada', password); // session token issued

// Authorization: every request — may YOU do THIS?
const doc = await new Parse.Query('Document').get('xKd91m');
// found if an ACL entry grants ada read · "not found" if not

doc.set('title', 'Renamed');
await doc.save(); // succeeds only if an entry grants ada WRITE

// Flutter / Dart — Back4app Flutter SDK
// Authentication: once — who are you?
final user = ParseUser('ada', password, null);
await user.login(); // session token issued

// Authorization: every request — may YOU do THIS?
final response = await QueryBuilder<ParseObject>(ParseObject('Document'))
    .query(); // returns only rows whose ACLs grant ada read

final doc = response.results!.first as ParseObject;
doc.set('title', 'Renamed');
await doc.save(); // succeeds only if an entry grants ada WRITE

// iOS / Swift — Back4app Swift SDK
// Authentication: once — who are you?
let user = try await User.login(username: "ada", password: password)
// session token issued

// Authorization: every request — may YOU do THIS?
guard var doc = try await Document.query("objectId" == "xKd91m").first()
else { return } // found only if an ACL entry grants ada read

doc.title = "Renamed"
_ = try await doc.save() // succeeds only if an entry grants ada WRITE

// Android / Kotlin — Back4app Android SDK
// Authentication: once — who are you?
val user = ParseUser.logIn("ada", password) // session token issued

// Authorization: every request — may YOU do THIS?
val doc = ParseQuery.getQuery<ParseObject>("Document").get("xKd91m")
// found if an ACL entry grants ada read · "not found" if not

doc.put("title", "Renamed")
doc.save() // succeeds only if an entry grants ada WRITE

Autenticación vs. autorización, lado a lado

Dos filas merecen sus notas al pie. Dónde corre: la autenticación se concentra de forma natural en el borde — un flujo de login, un proveedor de identidad — mientras que la autorización pertenece junto a los datos que protege, porque “¿puede este usuario tocar este objeto?” necesita el objeto. Falla como: los modelos de amenaza son disjuntos — el credential stuffing y el phishing atacan la autenticación (por eso MFA es la defensa authn de mayor palanca), mientras que la broken object-level authorization encabeza las listas de seguridad de APIs como la falla authz por antonomasia: usuario con sesión, objeto equivocado, nadie verificó.

401 y 403, con precisión

Los códigos de estado son la distinción vestida de números, y el RFC 9110 es exacto al respecto. 401 Unauthorized es el nombre engañoso más duradero de la historia: significa no autenticado — la solicitud “carece de credenciales de autenticación válidas”, la respuesta debe llevar un desafío WWW-Authenticate, y presentar credenciales puede arreglarlo. 403 Forbidden significa que el servidor entendió exactamente quién preguntaba y se niega de todos modos — re-autenticarse es inútil por definición. Y la especificación bendice una tercera jugada que los equipos de seguridad adoran: responder 404 en lugar de 403, para que un recurso prohibido no confirme su propia existencia. Acertar con los códigos no es pedantería; los clientes construyen su lógica de retry y re-login sobre ellos, y un 403 que debería ser un 401 manda a los usuarios contra un muro en lugar de a un formulario de login.

OAuth, OIDC y la confusión eterna

La confusión tiene una respuesta con forma de especificación. El título de OAuth 2.0 es “The OAuth 2.0 Authorization Framework” — mueve permisos con scopes, y la especificación de OpenID Connect existe precisamente porque OAuth por sí solo “es incapaz de proporcionar información sobre la autenticación de un usuario final”. OIDC agrega la capa de identidad: un ID token que afirma quién se autenticó, distinto del access token que afirma qué puede hacer el portador. Cada botón de “Iniciar sesión con…” es OIDC haciendo autenticación sobre la plomería de autorización de OAuth — un flujo, ambos conceptos, en capas limpias en lugar de confundidos.

Los tres errores que llegan a producción

Autorización del lado del cliente. Ocultar el botón de eliminar es diseño de interfaz; que el servidor decida si el delete se ejecuta es seguridad. Según OWASP: denegar por defecto, aplicar del lado del servidor y tratar los checks del cliente como pistas de UX. Con sesión ≠ permitido. Verificar la autenticación pero no la propiedad del objeto — /documents/42 servido a cualquier sesión válida — es broken object-level authorization, la clase de vulnerabilidad de APIs más común. La verificación es por objeto, por solicitud, sin excepciones. Orden del middleware. Autenticar primero, autorizar después, en el código como en el concepto: el middleware de identidad establece quién, y luego los handlers preguntan si — y una verificación de autorización que corre antes de establecer la identidad autoriza en silencio al anónimo.

Casos de uso comunes

• Login de la app + permisos sobre datos — el emparejamiento cotidiano: un flujo de auth, reglas por objeto para todo lo que sigue.
• Diseño de APIs — semántica de 401/403, tokens con scopes y checks a nivel de objeto como el lenguaje de errores del contrato.
• SaaS multi-tenant — autenticación compartida entre tenants; autorización acotada con firmeza dentro de cada uno.
• Herramientas de admin y soporte — autenticación step-up y autorización elevada, deliberadamente como eventos separados.
• Contenido público + privado — la lectura anónima como regla de autorización, prueba de que los dos conceptos corren de forma independiente.

¿Qué verificación te falta? Matriz de decisión

Limitaciones y trade-offs

• La división es conceptual, no siempre arquitectónica. Las apps pequeñas razonablemente corren ambas en un solo stack de middleware; la disciplina está en mantener los checks separados, no los servidores.
• Una authn fuerte no rescata a una authz débil. Las passkeys y MFA verifican la identidad a la perfección para un sistema que luego deja a cualquiera leer cualquier cosa — las fallas son independientes.
• La autorización por solicitud tiene un costo. Cachear decisiones, empujar las reglas hacia la capa de datos e indexar permisos son la manera de que “verificar todo” siga siendo rápido.
• El step-up difumina la línea de tiempo. Las acciones sensibles re-autentican a mitad de sesión — la autenticación no es estrictamente “una vez”, es “una vez por nivel de garantía”.
• La deriva de vocabulario causa bugs reales. Los equipos que dicen “auth” para ambas mitades escriben tickets, pruebas y códigos de error que las confunden; las palabras son la defensa más barata.

Autenticación y autorización en Back4app

Back4app es una plataforma open-source de Backend as a Service (BaaS) que combina base de datos gestionada, APIs REST y GraphQL generadas automáticamente, autenticación, almacenamiento de archivos y funciones serverless con Cloud Code. La arquitectura de la plataforma es la división: la clase User, las sesiones, el login social y el adaptador de MFA responden quién eres, produciendo un token de sesión revocable — y luego las ACLs, los permisos a nivel de clase y los roles responden qué puedes hacer, evaluados del lado del servidor en cada solicitud REST, GraphQL y Live Query, exactamente como muestran las pestañas de código: inicias sesión una vez y te juzgan por operación. La sección de errores se vuelve estructural: la autorización no puede quedar del lado del cliente porque Back4app la aplica detrás de la API, los objetos no autorizados vuelven como no encontrados en lugar de confirmar su existencia, y denegar por defecto es un checkbox en una clase. Las dos preguntas se mantienen separadas porque la plataforma nunca deja que se fusionen.