¿Código de estado HTTP 401 o 403? Cómo difieren los errores de autenticación y autorización
401 No Autorizado indica que el cliente no está autenticado, requiriendo credenciales válidas. 403 Prohibido significa que el cliente está autenticado pero carece de los permisos necesarios para acceder al recurso.
Product & Design
Cada vez que cargas una página web, realizas un pago o inicias sesión en una aplicación, hay una conversación invisible que sucede entre tu dispositivo y un servidor. Es un poco como enviar un mensaje y esperar una respuesta: a veces es un pulgar arriba, a veces es un cortés 'inténtalo de nuevo', y ocasionalmente, es un rotundo 'no'. Estas respuestas, conocidas como códigos de estado HTTP, son los héroes anónimos de internet, guiando silenciosamente el flujo de comunicación y asegurándose de que todo funcione sin problemas, o al menos informándote cuando no lo hace.
¿Qué son los códigos de estado HTTP?
Los códigos de estado HTTP son como señales en una conversación entre un cliente (como tu navegador o aplicación) y un servidor. Proporcionan actualizaciones rápidas y claras sobre lo que sucedió cuando hiciste una solicitud: si todo salió bien, si algo salió mal o si se requiere una acción adicional. Pensemos en esto como visitar una panadería bien organizada:
200: Todo es perfecto
Pides un croissant, y el panadero sonríe, te lo entrega y dice, "¡Aquí tienes!" Eso es un HTTP 200 OK: la solicitud fue exitosa y todo funcionó como se esperaba.
El código de estado HTTP 200 OK es uno de los códigos más utilizados, indicando que la solicitud del cliente fue recibida, entendida y procesada exitosamente por el servidor.
301: Nos mudamos
Llegas a tu panadería favorita, pero hay un cartel que dice, "Nos hemos mudado a la calle 123 New Street." Esto es un 301 Moved Permanently. El servidor dice a tu navegador que vaya a la nueva dirección automáticamente.
El código de estado HTTP 301 Moved Permanently indica que el recurso solicitado se ha movido permanentemente a una nueva URL. Este código de estado informa al cliente (por ejemplo, un navegador o cliente API) que actualice sus registros y use la nueva URL para futuras solicitudes.
404: Lo siento, no está aquí
Pides un scone de chocolate, y el panadero dice: "No hacemos eso aquí." Eso es un 404 Not Found: el recurso que buscas no existe en el servidor.
El código de estado HTTP 404 Not Found indica que el servidor no pudo encontrar el recurso solicitado. Esta respuesta significa que la solicitud del cliente era válida, pero el servidor no pudo localizar el recurso solicitado.
401: ¿Quién eres?
Intentas entrar en el salón VIP, pero el portero te detiene y dice, "Necesitas mostrar tu tarjeta de membresía." Eso es un 401 Unauthorized: se requiere autenticación antes de que puedas acceder al recurso.
El código de estado HTTP 401 Unauthorized indica que la solicitud del cliente no se ha aplicado porque carece de credenciales de autenticación válidas. El servidor requiere que el cliente se autentique para acceder al recurso solicitado.
403: No es para ti
Muestras tu tarjeta de membresía, pero el portero dice, "Solo los miembros platino pueden entrar." Eso es un 403 Forbidden: estás autenticado pero no tienes los permisos necesarios para acceder al recurso.
El código de estado HTTP 403 Forbidden indica que el servidor entiende la solicitud del cliente pero se niega a cumplirla porque el cliente no tiene los permisos necesarios. Esto es diferente de un estado 401 Unauthorized, ya que el cliente está autenticado (o la solicitud no requiere autenticación), pero el acceso al recurso está explícitamente denegado.
500: El horno está en llamas
Haces un pedido, pero de repente sale humo de la cocina. El panadero dice: "No podemos cumplir tu pedido; algo salió mal internamente." Eso es un 500 Internal Server Error: el servidor encontró un problema inesperado.
El código de estado HTTP 500 Internal Server Error indica que el servidor encontró una condición inesperada que le impidió cumplir la solicitud. Es una respuesta de error genérica y no proporciona detalles específicos sobre lo que salió mal.
503: Temporalmente no disponible
Visitas la panadería, pero hay un cartel que dice "Cerrado por Mantenimiento". La panadería volverá a abrir más tarde. Eso es un 503 Service Unavailable: el servidor está temporalmente incapaz de manejar tu solicitud, a menudo debido a sobrecarga o mantenimiento.
El código de estado HTTP 503 Service Unavailable indica que el servidor está temporalmente incapaz de manejar la solicitud. Esto podría deberse a sobrecarga del servidor, mantenimiento u otras condiciones temporales. A diferencia de un 500 Internal Server Error, un 503 implica que se espera que el problema se resuelva pronto.
Los códigos de estado HTTP son clave para mantener una comunicación eficiente entre clientes y servidores. Informan rápidamente a los clientes si sus solicitudes tuvieron éxito, fallaron o requieren acciones adicionales. Para los desarrolladores y profesionales de TI, entender estos códigos ayuda a depurar problemas, diseñar un mejor manejo de errores y mejorar la experiencia del usuario en general.
Piénsalos como señales profesionales y estandarizadas en la conversación continua de internet.
En este artículo, quiero centrarme en los errores 401 y 403, ya que están estrechamente relacionados con la autenticación (AuthN) y la autorización (AuthZ).
¿Cuándo usar 401 Unauthorized?
El código de estado HTTP 401 Unauthorized se usa cuando la solicitud del cliente requiere autenticación, pero está ausente, es inválida o ha fallado. Le dice al cliente que necesita autenticarse para acceder al recurso solicitado. La relación entre la autenticación y el código de estado 401 Unauthorized radica en el papel de la autenticación para determinar si una solicitud puede proceder.
401 unauthorized debe incluir un encabezado WWW-Authenticate, proporcionando detalles sobre cómo autenticar.
Entonces, ¿cuáles son los escenarios comunes para usar 401 Unauthorized?
-
Autenticación ausente
La solicitud no incluye las credenciales de autenticación requeridas. Por ejemplo: se realiza una solicitud a un endpoint de API protegido sin un encabezado de Autorización.
-
Credenciales de autenticación inválidas
El cliente proporciona credenciales, pero son incorrectas o no coinciden con lo que el servidor espera. Por ejemplo, un usuario envía una clave de API inválida o un token mal formado.
-
Token de autenticación expirado
El token de autenticación es válido pero ha expirado, requiriendo que el cliente se vuelva a autenticar. Por ejemplo, un token JWT con una fecha de expiración pasada (reclamo exp).
-
Encabezado de autorización ausente o mal formado
Se requiere el encabezado de autorización, pero no está proporcionado o está incorrectamente formateado.
-
Esquema de autenticación no soportado
El servidor no soporta el método de autenticación proporcionado por el cliente. Por ejemplo: el cliente envía un encabezado de autenticación básica, pero el servidor solo soporta tokens Bearer.
-
Sesión inválida o revocación de token
La sesión del usuario ha sido invalidada o su token ha sido revocado. Por ejemplo: un usuario cierra sesión, pero se usa el mismo token para acceder a un recurso protegido.
Ejemplo de respuesta
¿Cuándo usar 403 Forbidden?
El código de estado HTTP 403 Forbidden significa que el servidor entiende la solicitud y la identidad del cliente (si está autenticado) pero niega el acceso debido a permisos insuficientes. Señala claramente, "No se te permite hacer esto", asegurando límites de acceso claros y reforzando las políticas de seguridad.
La distinción entre 401 Unauthorized y 403 Forbidden radica en sus roles dentro de los contextos de autenticación y autorización.
La autorización es un mecanismo separado de la autenticación. Mientras que la autenticación identifica quién eres, la autorización determina si puedes acceder a recursos específicos y qué acciones puedes realizar en ellos.
Para revisar la diferencia detallada entre authN y authZ, revisa los siguientes artículos.
Entonces, ¿cuáles son los escenarios comunes para usar 403 Forbidden?
-
Autenticado pero carece de permiso
El cliente está autenticado pero no tiene los permisos o roles requeridos. Por ejemplo, un usuario con un rol de "espectador" intenta eliminar un archivo, lo cual requiere privilegios de "editor".
-
Acceso al recurso restringido
El acceso al recurso está intencionalmente restringido a usuarios o grupos específicos. Por ejemplo: un documento privado compartido con usuarios específicos es accedido por alguien que no está en la lista de acceso.
-
Bloqueo de IP o geográfico
La dirección IP del cliente o la ubicación geográfica está bloqueada por el servidor. Por ejemplo: un usuario de una región restringida intenta acceder a un servicio que solo opera en países específicos.
-
Acciones bloqueadas por política
El cliente está intentando realizar una acción prohibida por políticas o reglas del servidor. Por ejemplo: un usuario intenta modificar un recurso que está marcado como "solo lectura".
-
Recursos estáticos bloqueados
El servidor niega el acceso a archivos o directorios estáticos específicos por razones de seguridad.
Ejemplo: un usuario intenta acceder a un archivo .htaccess o a un archivo de configuración del servidor.
-
Cuenta suspendida o desactivada
La cuenta del cliente está desactivada o bloqueada debido a violaciones o inactividad. Por ejemplo: un usuario con una cuenta suspendida intenta iniciar sesión o acceder a recursos.
-
La acción requiere permisos elevados
La acción solicitada requiere privilegios especiales (por ejemplo, admin o superusuario). Por ejemplo: un usuario estándar intenta acceder a endpoints solo para administradores.
Ejemplo de respuesta:
¿Cómo puedo solucionar un error 401 no autorizado?
Un error 401 generalmente indica que se requiere autenticación y ha fallado.
Verificar credenciales
Asegúrate de que el encabezado de Autorización esté presente y correctamente formateado y verifica que las credenciales (clave API, token o contraseña) sean correctas y no estén expiradas. Ingresar un nombre de usuario o contraseña incorrectos es una de las causas más frecuentes de un error 401.
Confirmar método de autenticación
El servidor puede esperar un método de autenticación diferente al que se está proporcionando. Esto puede suceder si el cliente y el servidor no están alineados en el protocolo de autenticación. Usa el método correcto (por ejemplo, Básico, Bearer, Clave API) según lo especificado por el servidor y verifica la sintaxis correcta en los encabezados.
Inspeccionar la respuesta del servidor
Revisa el cuerpo de la respuesta en busca de detalles de error y observa el encabezado WWW-Authenticate para instrucciones de autenticación.
Verificar la solicitud
Confirma que el endpoint, los parámetros de consulta y el host sean correctos y asegúrate de que el recurso al que estás accediendo requiere autenticación.
Comprobar problemas de token
Decodifica e inspecciona el token (por ejemplo, con https://logto.io/jwt-decoder) para validar su validez, expiración y reclamaciones y compara la audiencia (aud) del token con los requisitos de la API.
¿Cómo puedo solucionar un error 403 prohibido?
Un error 403 prohibido generalmente significa que el proceso de autorización se completó, pero se negó el acceso. Para solucionar este error, considera las siguientes condiciones:
Verificar permisos
Confirma que tu cuenta, clave API o token tiene los permisos requeridos para el recurso. Verifica si el recurso está restringido a roles o grupos específicos.
Asegurarse de que la autenticación sea correcta
Asegúrate de que estás autenticado correctamente (por ejemplo, con un token o credenciales válidas).
Verifica el método de autenticación requerido por el servidor.
Validar el recurso
Confirma que el recurso solicitado existe y tienes acceso a él. Si usas APIs, verifica los requisitos del endpoint en la documentación.
Buscar bloqueo de IP o ubicación
Verifica si tu dirección IP o ubicación geográfica está restringida por el servidor.
Revisar políticas del servidor
Asegúrate de que la acción solicitada no viola las reglas o políticas del servidor (por ejemplo, acceder a un recurso de solo lectura).
Inspeccionar la respuesta del servidor
Examina el cuerpo de la respuesta en busca de detalles que expliquen la razón del error 403.
¿Puede una solicitud única devolver los códigos de estado 401 y 403?
No, una solicitud HTTP única no puede devolver simultáneamente los códigos de estado 401 Unauthorized y 403 Forbidden porque una respuesta HTTP solo puede incluir un código de estado.
El uso práctico de los códigos de error 401 y 403 en la autenticación y autorización
En el desarrollo moderno de aplicaciones, 401 Unauthorized y 403 Forbidden son dos códigos de estado HTTP que los desarrolladores encuentran con frecuencia. Aunque pueden parecer similares, sus significados y casos de uso son claramente diferentes. Para aclarar sus diferencias, este artículo explora ejemplos prácticos de estos códigos en escenarios como autenticación, autorización, multi-tenencia y autenticación multifactor (MFA).
- Escenario de inicio de sesión: un usuario intenta acceder a una página protegida sin iniciar sesión o sin proporcionar credenciales válidas. El servidor responde y lanza un error 401 Unauthorized: “Necesitas iniciar sesión o proporcionar credenciales válidas para acceder a esta página.”
- Escenario de control de acceso: el mismo usuario inicia sesión exitosamente pero intenta acceder a una página solo para administradores sin el rol de administrador requerido. El servidor responde y lanza un 403 Forbidden: “Estás autenticado, pero no tienes permiso para acceder a esta página.”
- Escenario multi-inquilino: el mismo usuario inicia sesión pero pertenece a Inquilino A y intenta acceder a un recurso en Inquilino B, donde no tiene acceso. El servidor responde y lanza un 403 Forbidden: “Estás autenticado, pero no tienes permiso para acceder a este recurso en Inquilino B.”
- Escenario MFA: un usuario intenta iniciar sesión pero no ha completado la Autenticación Multifactor (MFA) requerida. El servidor responde y lanza un error 401 Unauthorized: “La autenticación está incompleta. Por favor completa MFA para proceder.”
Usando Logto como proveedor de autenticación y autorización
Logto es principalmente un proveedor de autenticación, ofreciendo métodos clave como inicio de sesión sin contraseña, correo electrónico y contraseña, MFA, SSO Empresarial e inicio de sesión social, todos basados en protocolos de estándares abiertos como OIDC, OAuth 2.0, y SAML.
Logto Cloud también proporciona características esenciales de autorización, incluyendo Control de Acceso Basado en Roles (RBAC), Organizaciones (Multi-Tenencia) y Reclamaciones de Token Personalizadas para satisfacer una variedad de necesidades de autorización.