Cada desarrollador que ha integrado una API de terceros ha golpeado el mismo muro: los documentos dicen "autenticar con autenticación básica," pegas tu clave y secreto en una solicitud, y el servidor responde con un plano 401 Unauthorized y no hay pistas sobre por qué. Nueve de cada diez veces la credencial se codificó ligeramente mal y no hay nada en el error que te lo diga. He creado y consumido suficientes API en complementos de WordPress y backends de Laravel como para haber perdido una cantidad vergonzosa de tiempo exactamente en esto, así que puse un generador de autenticación básico según Toolz.dev eso construye el encabezado correctamente cada vez y decodifica uno cuando necesita verificarlo. Esta es la guía para ello y para el esquema detrás de él.
TL;Dr: HTTP Basic Authentication envía un nombre de usuario y contraseña como
base64(username:password)en elAuthorizationencabezado. La herramientaz generador de autenticación básico convierte un nombre de usuario y una contraseña en el encabezado exacto, un comando curl listo para ejecutar, un fragmento de búsqueda y el formulario de información de usuario de URL, y decodifica los tokens existentes. Codifica a través de UTF-8 para que sobrevivan las credenciales que no son ASCII, advierte cuando el nombre de usuario contiene dos puntos y se ejecuta completamente en el lado del cliente.
¿qué es la autenticación básica HTTP?
La autenticación básica HTTP es el esquema de credenciales más simple que define la web. Se especifica en RFC 7617, que se encuentra encima del marco general de autenticación HTTP en RFC 7235. La idea es mínima: para demostrar quién eres, envías un Authorization encabezado cuyo valor es la palabra Basic, un espacio, y luego la codificación base64 de su nombre de usuario y contraseña unidos por dos puntos.
Concretamente, si tu nombre de usuario es admin y tu contraseña lo es secret, el cliente forma la cadena admin:secret, lo codifica como UTF-8 bytes, base64 codifica esos bytes para obtener YWRtaW46c2VjcmV0, și trimite:
Authorization: Basic YWRtaW46c2VjcmV0
Ese es el esquema completo. No hay apretón de manos, ni nonce, ni hash. Su simplicidad es exactamente la razón por la que ha sobrevivido: es trivial de implementar en ambos extremos, y para herramientas internas, registros privados, webhooks e innumerables API sigue siendo el valor predeterminado. El problema, y es importante, es que la codificación es completamente reversible, lo que da forma a todo sobre cómo debe usarla.
¿la codificación base64 es lo mismo que el cifrado?
No, y esto es lo más importante que hay que entender sobre la autenticación básica. Base64, definida en RFC 4648, es una codificación de transporte. Su propósito es representar datos binarios o de texto utilizando un conjunto seguro de 64 caracteres imprimibles para que sobrevivan al envío a través de sistemas que esperan texto. No es un cifrado, no utiliza clave y revertirlo da un paso. Cualquiera que pueda ver YWRtaW46c2VjcmV0 puede decodificarlo nuevamente admin:secret al instante, que es lo que hace esta herramienta y el modo de decodificación #39;s.
La consecuencia es que la autenticación básica no proporciona ninguna confidencialidad por sí sola. La credencial se envía efectivamente de forma clara, simplemente con un ligero disfraz. Por eso la única regla no negociable de la autenticación básica es que sólo debe viajar a través de HTTPS. TLS cifra toda la solicitud, incluida la Authorization encabezado, por lo que la credencial base64 está protegida en tránsito. Envíe la autenticación básica a través de HTTP simple y habrá publicado su contraseña para cualquier persona en la ruta de la red.
Trabajo este punto porque el paso base64 engaña a la gente haciéndoles pensar que la credencial está codificada de alguna manera significativa. No lo es. Trate el token base64 con el mismo cuidado con el que trataría la contraseña sin formato, porque son trivialmente interconvertibles. El herramientas en línea de privacidad de datos la guía cubre por qué esta herramienta realiza la codificación en su navegador en lugar de en un servidor, lo cual para una credencial activa es el punto.
¿cómo se construye paso a paso el encabezado de autenticación Básico?
La construcción consta de cuatro pequeños pasos, y equivocarse ligeramente alguno de ellos produce una credencial que falla silenciosamente:
- Únete con dos puntos. Forma la cuerda
username:password. Los dos puntos son el delimitador. - Codificar como UTF-8. Convierta esa cadena en bytes usando UTF-8. Esto es importante para cualquier carácter que no sea ASCII.
- Base64-codifica los bytes. Aplique la base estándar64 para producir el token.
- Prefijar con
Basic. El valor final del encabezado esBasicseguido del token.
los generador hace los cuatro y le entrega el encabezado terminado. También produce los formularios que realmente pega en una terminal o en una base de código: un comando curl usando -u bandera, un comando de curl con lo explícito -H 'Authorization: Basic ...' encabezado, un fragmento de búsqueda, el token básico por sí solo y el formulario de información de usuario de URL https://user:pass@host. Diferentes tareas quieren diferentes formas, y volver a escribir la base64 a mano es precisamente donde se introducen los errores.
¿Por qué el nombre de usuario importa más que la contraseña?
Hay una asimetría en el esquema que hace tropezar a las personas constantemente y proviene directamente del primer paso. La credencial está dividida en primero dos puntos. Eso significa que el nombre de usuario no puede contener dos puntos, porque el servidor leería los primeros dos puntos de su nombre de usuario como límite y entregaría el resto al campo de contraseña. La contraseña, por el contrario, puede contener tantos dos puntos como desee, ya que todo lo que aparece después de los primeros dos puntos es la contraseña.
RFC 7617 establece esto directamente: el ID de usuario no debe contener dos puntos. Esto es fácil de violar sin darse cuenta, especialmente cuando el nombre de usuario es en sí mismo algo estructurado como una clave API o un identificador con forma de correo electrónico que incluye dos puntos. El generador observa exactamente esto y le advierte cuando el nombre de usuario contiene dos puntos, porque la credencial resultante se decodificará con la división en el lugar equivocado y producirá un 401 que no le dará ninguna pista sobre la causa.
Aquí está la regla de una tabla, porque vale la pena ser inequívoca.
| prado | ¿puede contener dos puntos? | Razón |
|---|---|---|
| nombre de usuario | prohibido | Los primeros dos puntos son el delimitador |
| contraseña | sí | Todo lo que esté después de los primeros dos puntos es la contraseña |
He depurado exactamente esta falla en la naturaleza, donde un servicio emitió API " nombres de usuario" que ocasionalmente contenía dos puntos y la integración funcionó para la mayoría de los clientes y misteriosamente falló para algunos. La herramienta 's advertencia se habría salvado esa tarde.
¿por qué es importante la codificación UTF-8?
Para un nombre de usuario y contraseña totalmente ASCII, el paso de codificación es invisible; cada carácter es un byte y base64 hace lo suyo. En el momento en que una credencial contiene una letra acentuada, una escritura no latina o un emoji, la codificación de bytes se vuelve decisiva. RFC 7617 recomienda UTF-8 precisamente para que el cliente y el servidor acuerden los bytes de estos caracteres.
Un codificador ingenuo que asume que un carácter es un byte, o que se apoya en una API de navegador con comportamiento heredado, se corromperá café investigaciones operacionales пароль en los bytes incorrectos, el token base64 que produce no coincidirá con lo que un servidor compatible calculó a partir de la misma credencial. El resultado es otro 401 silencioso. Este generador codifica la credencial a través de UTF-8 a mano, por lo que se parece a una contraseña café:naïve produce exactamente los bytes que enviaría un cliente RFC 7617 y el lado de decodificación lo invierte fielmente. Si alguna vez ha tenido una credencial que funcionó para un compañero de equipo y no para otro, un carácter que no sea ASCII codificado de manera inconsistente es el principal sospechoso.
¿cómo decodigo un token de autenticación básico?
Debido a que la codificación es reversible, verificar una credencial es tan fácil como producir una. Toma la parte después Basic , base64-decódelo, lea el resultado como UTF-8 y divídalo en los primeros dos puntos. El generador's el modo de decodificación hace esto: pegar un completo Authorization: Basic ... línea, un desnudo Basic ... valor, o simplemente el token, y le muestra el nombre de usuario y contraseña que lleva.
Esto es realmente útil, no sólo una curiosidad. Cuando le entregan una credencial de trabajo y le piden que la reproduzca en un nuevo entorno, la decodificación le indica exactamente qué nombre de usuario y contraseña codifica para que pueda configurarlos correctamente. Cuando falla una integración, decodificar el token que realmente está enviando y compararlo con lo que pretendía suele ser la forma más rápida de detectar un espacio perdido, un campo incorrecto o dos puntos en el lugar equivocado. Y es un vívido recordatorio del punto de confidencialidad anterior: si puedes decodificarlo tan fácilmente, también puede hacerlo cualquiera que lo intercepte a través de HTTP simple.
Donde el generador encaja con las otras herramientas
La autenticación básica es una de varias herramientas de credenciales y solicitudes en el sitio que comparten el mismo modelo sin carga del lado del cliente. Cuando el token que está inspeccionando es un token portador en lugar de una autenticación básica, el Decodificador JWT lee los reclamos de un token web JSON. Cuando necesita un hash en lugar de una codificación, para obtener una suma de verificación o un resumen de contraseña, el generador hash lo calcula. Cuando solo desea codificar o decodificar una base64 arbitraria en lugar de una credencial específicamente, el convertidor base64 maneja el caso general. Y cuando estás depurando la solicitud y quieres saber qué le envió el cliente, el analizador de agentes de usuario lee el encabezado User-Agent.
Para obtener un mapa más amplio de cómo funcionan juntas estas utilidades de solicitud y respuesta, el Kit de herramientas para desarrolladores web roundup recorre una sesión de depuración realista y el Herramientas de productividad para desarrolladores la guía cubre el montaje de un conjunto personal de ellos. La autenticación básica rara vez aparece de forma aislada; Por lo general, es una línea de una solicitud que está intentando hacer funcionar.
Un ejemplo trabajado: conectar una integración API
Permítanme fundamentar esto en la tarea que más encendí. Está integrando un servicio de terceros cuyos documentos dicen que se autentican con autenticación básica utilizando una clave API como nombre de usuario y una contraseña vacía, o una clave y un par secreto. Los documentos le dan las credenciales pero no el encabezado, y la primera solicitud falla.
La ruta confiable es crear el encabezado explícitamente y probarlo con curl antes de escribir una línea de código de aplicación. Pegue la clave y el secreto en el generador, copia el curl -H formúlelo y ejecútelo con un punto final conocido. Si curl tiene éxito y su código no, el problema está en la construcción de la solicitud de code's, no en la credencial, y acaba de reducir el espacio de búsqueda a la mitad. Si curl también falla, la credencial en sí está equivocada y la decodificación del token confirma exactamente qué campo está desactivado.
En un complemento de WordPress, a menudo necesito llamar a una API externa desde PHP, y el valor de encabezado correcto es a lo que ingreso wp_remote_get vía el Authorization argumento del encabezado. En Laravel entra en el withHeaders llame al cliente HTTP o uso el framework's withBasicAuth helper, que crea el mismo encabezado para mí. De cualquier manera, tener el valor de encabezado en buen estado del generador significa que estoy depurando el código de mi solicitud con una credencial que ya he demostrado que funciona, en lugar de depurar ambas a la vez. El caso de contraseña vacía es donde el generador se queda, porque es fácil olvidarlo key: con dos puntos finales hay una credencial diferente y, a menudo, correcta key solo.
La última disciplina es la de seguridad. No pegue el encabezado resultante en un documento compartido, un ticket o un chat, y no envíe autenticación básica a nada que no sea HTTPS. El token es la contraseña. Porque esta herramienta codifica en tu navegador y nunca carga nada, generar la credencial es seguro; donde va después está sobre ti.
¿cuándo debo utilizar la autenticación básica y cuándo no?
La autenticación básica no es la herramienta adecuada para cada trabajo y saber dónde encaja te mantiene fuera de problemas. Su punto fuerte es la simplicidad: para llamadas de servidor a servidor, herramientas internas, registros de paquetes privados, trabajos de CI y webhooks donde los dos extremos ya confían entre sí y todo se ejecuta a través de HTTPS, es difícil de superar. No hay nada que negociar, ni token que actualizar, y cada cliente y biblioteca HTTP lo admite de forma inmediata. Cuando controlas ambos lados y la conexión está cifrada, la autenticación básica es una opción perfectamente razonable que ha seguido funcionando durante treinta años.
Sus debilidades aparecen en el momento en que sales de esa casilla. Debido a que la credencial se envía en cada solicitud, una sola línea de registro filtrada o un proxy que registra encabezados la expone permanentemente y rotarla significa cambiarla a todas partes a la vez. No tiene concepto de alcance, por lo que una credencial básica es todo o nada: no puede otorgar acceso de solo lectura ni caducar después de una hora. Y en su lugar coloca una contraseña real y de larga duración en el cable de cada llamada, mientras que los esquemas basados en tokens le permiten entregar una credencial de corta duración y alcance limitado.
Para la autenticación orientada al usuario, o en cualquier lugar donde necesite alcances, vencimiento o revocación, un token portador es el mejor modelo, y el Decodificador JWT es la herramienta complementaria para inspeccionarlos. Una regla general útil: busque la autenticación básica para llamadas de máquina a máquina que controle completamente y busque tokens cuando esté involucrado un tercero, una sesión de navegador o un límite de permiso. La siguiente tabla resume el comercio.
| Utilice la autenticación básica para | Prefiere tokens para |
|---|---|
| La API de servidor a servidor lo llama a controlar | Sesiones de cara al usuario |
| Herramientas internas y registros privados | Acceso con alcance o de solo lectura |
| Empleos de CI y webhooks sobre HTTPS | Credenciales que deben caducar |
Preguntas frecuentes
¿qué es la autenticación básica HTTP? HTTP Basic Authentication es un esquema donde un cliente envía un nombre de usuario y contraseña con cada solicitud en el encabezado de Autorización. El valor es la palabra Básico seguida de la codificación base64 de nombre de usuario:contraseña. Está definido en RFC 7617 y es la forma más sencilla para que un servidor verifique las credenciales.
¿cómo se construye el encabezado de autenticación básico? Únase al nombre de usuario y la contraseña con dos puntos para formar nombre de usuario: contraseña, codifique esa cadena como UTF-8 bytes, base64 codifique los bytes y prefije el resultado con Básico. El encabezado final es Autorización: Básico seguido de ese token.
¿es segura la autenticación básica? Sólo a través de HTTPS. Base64 codifica, no cifra, por lo que cualquiera que pueda leer el encabezado puede decodificar la contraseña al instante. La autenticación básica no proporciona confidencialidad por sí sola y siempre debe enviarse a través de una conexión TLS para estar seguro.
¿puede el nombre de usuario contener dos puntos? No. Los primeros dos puntos separan el nombre de usuario de la contraseña, por lo que se malinterpretarían dos puntos en el nombre de usuario como límite y se dividiría la credencial en el lugar equivocado. La contraseña puede contener cualquier número de dos puntos. El generador le avisa si el nombre de usuario tiene uno.
¿cómo decodigo un token de autenticación básico? Tome la parte base64 después de Basic, decodéciela base64 y léala como texto UTF-8. El resultado es nombre de usuario:contraseña, dividida en los primeros dos puntos. Pegue cualquier encabezado de autenticación básico en la herramienta 's modo de decodificación para hacerlo al instante.
¿cuál es el equivalente al rizo? curl -u nombre de usuario:contraseña https://example.com hace lo mismo, porque curl construye el encabezado Autorización: Básico para usted a partir del valor -u. La herramienta muestra tanto ese formulario como el formulario de encabezado -H explícito para que pueda copiar lo que encaje.
¿Esta herramienta envía mis credenciales a alguna parte? No. La codificación y decodificación se ejecutan completamente en su navegador con JavaScript. Su nombre de usuario y contraseña nunca se cargan en ningún servidor, por lo que es seguro usarlos con credenciales reales y activas.
¿por qué utilizar la codificación UTF-8 para la credencial? RFC 7617 recomienda UTF-8 para que los nombres de usuario y contraseñas que no sean ASCII se codifiquen de manera consistente entre el cliente y el servidor. Un codificador que supone que ASCII corrompería letras acentuadas o scripts no latinos, produciendo un token que el servidor no puede igualar.
