401 significa no autenticado, 403 significa autenticado pero sin permiso. Responde cuatro preguntas sobre una petición y obtén el estado correcto, con cabeceras y código.
Devuelve 401 Unauthorized cuando la petición no trae credenciales válidas: sin token, una sesión caducada, una firma incorrecta. Iniciar sesión podría arreglarlo, y la respuesta debe llevar una cabecera WWW-Authenticate. Devuelve 403 Forbidden cuando sabes quién hace la petición y aun así no puede hacer esto, de modo que volver a iniciar sesión no cambia nada.
Unauthorized frente a Forbidden
Responde cuatro preguntas sobre la petición que tu servidor está rechazando. El selector devuelve el estado que debes enviar, la cabecera que lo acompaña y un motivo de una línea que puedes poner en un comentario del código. También cubre el caso en que prefieres no admitir que el recurso existe.
401 dice que el servidor no sabe quién eres o que no aceptó la prueba que enviaste. 403 dice que sabe quién eres y que la respuesta sigue siendo no.
Sí. RFC 9110 dice que un servidor que genera una respuesta 401 debe enviar al menos un campo de cabecera WWW-Authenticate con un desafío, como Bearer en las APIs con token.
401. Las credenciales ya no son válidas, y unas nuevas lo arreglarían. Un desafío Bearer puede indicarlo con error="invalid_token".
Sí. La especificación permite que un servidor envíe 404 en lugar de 403 para ocultar si el recurso existe. Es una opción habitual para ids que pertenecen a otros usuarios.
Puede ser. Los servidores envían 403 ante cualquier rechazo que consideran definitivo para esa petición: reglas de IP, falta de permisos sobre archivos, una regla de firewall o una comprobación de rol fallida. El cuerpo de la respuesta o el log del servidor suelen indicar cuál.
verifyToken representa tu propia comprobación de sesión o de JWT. El orden importa: primero autenticar, luego autorizar.
Una ruta del código envía al usuario a iniciar sesión; la otra explica el rechazo.
Sí
No
¿La petición traía credenciales (cookie de sesión, token, cabecera Authorization)?
¿Esas credenciales eran válidas y no estaban caducadas?
¿Quien hace la petición puede realizar esta acción sobre este recurso?
¿Hay que impedir que quien no tiene acceso sepa que el recurso existe?
Envía esto
Nadie ha iniciado sesión. Pide credenciales con un desafío.
Llegaron credenciales, pero se rechazaron. Unas nuevas lo arreglarían.
Se sabe quién hace la petición y no tiene permiso. Volver a iniciar sesión no servirá.
Quien hace la petición no tiene permiso y prefieres no revelar que el recurso existe.
Autenticado y con permiso. Atiende la petición.
No se pregunta, porque una respuesta anterior ya decidió el estado.
Empieza gratis · Sin tarjeta de crédito