Cada desenvolvedor que integrou uma API de terceiros atingiu a mesma parede: os documentos dizem " autenticar com autenticação básica e quot; você cola sua chave e segredo em uma solicitação e o servidor responde com uma versão plana 401 Unauthorized e nenhuma dica sobre o porquê. Nove vezes em cada dez a credencial foi codificada um pouco errada, e não há nada no erro para dizer que. Eu construí e consumi APIs suficientes em plugins WordPress e backends Laravel para ter desperdiçado uma quantidade embaraçosa de tempo exatamente nisso, então EU coloquei um gerador básico de autenticação em Toolz.dev que constrói o cabeçalho corretamente todas as vezes e decodifica um de volta quando você precisa verificar Este é o guia para ele e para o esquema por trás dele.
tl;dr: A autenticação básica HTTP envia um nome de usuário e uma senha como
base64(username:password)noAuthorizationcabeçalho. O Toolz gerador básico de autenticação transforma um nome de usuário e senha no cabeçalho exato, um comando curl pronto para execução, um trecho de busca e o formulário de informações do usuário da URL e decodifica os tokens existentes de volta. Ele codifica UTF-8 para que credenciais não ASCII sobrevivam, avisa quando o nome de usuário contém dois pontos e é executado inteiramente no lado do cliente.
O que é autenticação básica HTTP?
HTTP Basic Authentication é o esquema de credenciais mais simples que a web define É especificado em RFC 7617, que fica no topo da estrutura geral de autenticação HTTP em RFC 7235. A ideia é mínima: para provar quem você é, você envia um Authorization cabeçalho cujo valor é a palavra Basic, um espaço e, em seguida, a codificação base64 do seu nome de usuário e senha unidos por dois pontos.
Concretamente, se o seu nome de usuário for admin e a sua senha é secret, o cliente forma a string admin:secret, codifica-o como bytes UTF-8, base64-codifica esses bytes para obter YWRtaW46c2VjcmV0e envia:
Authorization: Basic YWRtaW46c2VjcmV0
Esse é todo o esquema Não há aperto de mão, nem nonce, nem hashing Sua simplicidade é exatamente o motivo pelo qual sobreviveu: é trivial implementar em ambas as extremidades, e para ferramentas internas, registros privados, webhooks e inúmeras APIs ainda é o padrão A captura, e é grande, é que a codificação é completamente reversível, o que molda tudo sobre como você deve usá-la.
A codificação base64 é igual à criptografia?
Não, e esta é a coisa mais importante a ser entendida sobre a autenticação básica. Base64, definido em RFC 4648, é uma codificação de transporte Seu propósito é representar dados binários ou de texto usando um conjunto seguro de 64 caracteres imprimíveis para que ele sobreviva sendo enviado através de sistemas que esperam texto Não é uma cifra, não usa chave, e invertê-lo dá um passo Qualquer um que possa ver YWRtaW46c2VjcmV0 pode decodificá-lo de volta para admin:secret instantaneamente, que é o que esta ferramenta & #39; s modo de decodificação faz.
A consequência é que a autenticação Básica fornece confidencialidade zero por conta própria A credencial é efetivamente enviada de forma clara, apenas usando um disfarce fino É por isso que a única regra não negociável do Basic auth é que ele só deve viajar por HTTPS. O TLS criptografa toda a solicitação, incluindo o Authorization cabeçalho, então a credencial base64 é protegida em trânsito Envie autenticação básica por HTTP simples e você publicou sua senha para qualquer pessoa no caminho da rede.
Eu trabalho este ponto porque o passo base64 engana as pessoas a pensar que a credencial é embaralhada de alguma forma significativa Não é. Trate o token base64 com o mesmo cuidado que você trataria a senha bruta, porque eles são trivialmente interconversíveis O ferramentas online de privacidade de dados o guia cobre por que esta ferramenta faz a codificação no seu navegador, em vez de em um servidor, o que para uma credencial ao vivo é o ponto principal.
Como o cabeçalho de autenticação Básico é construído, passo a passo?
A construção é de quatro pequenos passos, e obter qualquer um deles um pouco errado produz uma credencial que falha silenciosamente:
- Junte-se a dois pontos. Formar a corda
username:password. Os dois pontos são o delimitador. - Codifique como UTF-8. Transforme essa string em bytes usando UTF-8. isso é importante para qualquer caractere não ASCII.
- Base64-codificar os bytes. Aplique o padrão base64 para produzir o token.
- Prefixo com
Basic. O valor final do cabeçalho éBasicseguido pelo token.
o gerador faz todos os quatro e entrega-lhe o cabeçalho acabado Também produz os formulários que você realmente colar em um terminal ou uma base de código: um comando curl usando o -u flag, um comando curl com o explícito -H 'Authorization: Basic ...' cabeçalho, um trecho de busca, o token simples por conta própria e o formulário URL userinfo https://user:pass@host. Tarefas diferentes querem formas diferentes, e redigitar a base64 manualmente é precisamente onde os erros surgem.
Por que o nome de usuário importa mais do que a senha?
Há uma assimetria no esquema que faz as pessoas tropeçarem constantemente, e vem direto da etapa um A credencial é dividida no primeiro dois pontos. Isso significa que o nome de usuário não pode conter dois pontos, porque o servidor leria os primeiros dois pontos do seu nome de usuário como limite e entregaria o restante ao campo de senha. A senha, por outro lado, pode conter quantos dois pontos desejar, já que tudo depois dos primeiros dois pontos é a senha.
RFC 7617 afirma isso diretamente: o usuário-id não deve conter dois pontos Isso é fácil de violar sem perceber, especialmente quando o nome de usuário é em si algo estruturado como uma chave API ou um identificador em forma de e-mail que passa a incluir dois pontos O gerador observa exatamente isso e avisa quando o nome de usuário contém dois pontos, porque a credencial resultante irá decodificar com a divisão no lugar errado e produzir um 401 que não lhe dá nenhuma pista sobre a causa.
Aqui está a regra em uma tabela, porque vale a pena ser inequívoca.
| campo | Pode conter dois pontos? | Razão |
|---|---|---|
| nome de usuário | não | O primeiro cólon é o delimitador |
| senha | sim | Tudo depois dos primeiros dois pontos é a senha |
Eu depurei esta falha exata na natureza, onde um serviço emitiu API & quot; usernames" que ocasionalmente continha dois pontos e a integração funcionou para a maioria dos clientes e misteriosamente falhou por alguns O aviso tool' s teria salvo naquela tarde.
Por que a codificação UTF-8 é importante?
Para um nome de usuário e senha totalmente ASCII, a etapa de codificação é invisível; cada caractere é um byte e a base64 faz o que quer. No momento em que uma credencial contém uma letra acentuada, um script não latino ou um emoji, a codificação de bytes se torna decisiva. A RFC 7617 recomenda UTF-8 precisamente para que cliente e servidor concordem com os bytes desses caracteres.
Um codificador ingênuo que assume que um caractere é um byte, ou que se apoia em uma API de navegador com comportamento legado, irá corromper café ou пароль nos bytes errados, e o token base64 que ele produz não corresponderá ao que um servidor compatível calculou a partir da mesma credencial O resultado é outro 401 silencioso Este gerador codifica a credencial sobre UTF-8 manualmente, então uma senha como café:naïve produz exatamente os bytes que um cliente RFC 7617 enviaria, e o lado de decodificação inverte fielmente Se você já teve uma credencial que funcionou para um companheiro de equipe e não para outro, um caractere não ASCII codificado de forma inconsistente é o principal suspeito.
Como decodifico um token de autenticação Básico?
Como a codificação é reversível, verificar uma credencial é tão fácil quanto produzir uma. Pegue a parte depois Basic , base64-decodificá-lo, ler o resultado como UTF-8, e dividir no primeiro dois pontos O gerador e#39;s o modo de decodificação faz isso: cole um full Authorization: Basic ... linha, nua Basic ... valor, ou apenas o token, e mostra o nome de usuário e a senha que ele carrega.
Isso é genuinamente útil, não apenas uma curiosidade Quando você recebe uma credencial de trabalho e é solicitado a reproduzi-la em um novo ambiente, a decodificação informa exatamente qual nome de usuário e senha ela codifica para que você possa configurá-los corretamente Quando uma integração falha, decodificar o token que você está realmente enviando e compará-lo com o que você pretendia é muitas vezes a maneira mais rápida de detectar um espaço perdido, um campo errado ou dois pontos no lugar errado E é um lembrete vívido do ponto de confidencialidade acima: se você pode decodificá-lo tão facilmente, qualquer um que o intercepte em HTTP simples.
Onde o gerador se encaixa com as outras ferramentas
A autenticação básica é uma das várias ferramentas de credenciais e solicitações no site que compartilham o mesmo modelo sem upload do lado do cliente. Quando o token que você está inspecionando é um token de portador em vez da autenticação básica, o Decodificador JWT lê as reivindicações de um Token Web JSON Quando você precisa de um hash em vez de uma codificação, para uma soma de verificação ou um resumo de senha, o gerador hash calcula-o Quando você só quer codificar ou decodificar base64 arbitrária em vez de uma credencial especificamente, o conversor base64 lida com o caso geral E quando você está depurando a solicitação em si e quer saber qual cliente a enviou, o analisador de agente de usuário lê o cabeçalho User-Agent.
Para um mapa mais amplo de como esses utilitários de solicitação e resposta funcionam juntos, o Kit de ferramentas para desenvolvedores web roundup passa por uma sessão de depuração realista e o Ferramentas de produtividade do desenvolve o guia cobre a montagem de um conjunto pessoal deles O autenticação básica raramente aparece isoladamente; geralmente é uma linha em uma solicitação que você está tentando fazer funcionar.
Um exemplo prático: conectar uma integração de API
Deixe-me aterrar isso na tarefa que EU mais acertei Você está integrando um serviço de terceiros cujos docs dizem para autenticar com o Basic auth usando uma chave de API como nome de usuário e uma senha vazia, ou um par de chaves e secretos Os docs dão as credenciais, mas não o cabeçalho, e a primeira solicitação falha.
O caminho confiável é construir o cabeçalho explicitamente e testá-lo com curl antes de escrever uma linha de código de aplicativo Cole a chave e o segredo no gerador, copie o curl -H formulário, e executá-lo contra um ponto final conhecido Se curl for bem sucedido e seu código não, o problema está em seu código' s solicitar construção, não a credencial, e você acabou de cortar o espaço de pesquisa pela metade Se curl também falhar, a credencial em si está errada, e decodificar o token confirma exatamente qual campo está desligado.
Em um plugin WordPress, muitas vezes preciso chamar uma API externa de PHP, e o valor correto do cabeçalho é o que EU alimento wp_remote_get via o Authorization argumento do cabeçalho. Em Laravel, ele entra no withHeaders ligue para o cliente HTTP ou eu uso o framework's withBasicAuth helper, que constrói o mesmo cabeçalho para mim De qualquer forma, ter o valor de cabeçalho conhecido-bom do gerador significa que estou depurando meu código de solicitação contra uma credencial que já provei funciona, em vez de depurar ambos de uma só vez O caso de senha vazia é onde o gerador ganha seu sustento, porque é fácil esquecer isso key: com dois pontos à direita está uma credencial diferente e muitas vezes correta key sozinho.
A última disciplina é a de segurança Não cole o cabeçalho resultante em um documento compartilhado, um ticket ou um chat, e não envie autenticação básica sobre nada além de HTTPS O token é a senha Porque esta ferramenta codifica em seu navegador e nunca carrega nada, gerar a credencial é seguro; onde vai depois é em você.
Quando devo usar o autenticação Básica e quando não devo?
O auth básico não é a ferramenta certa para cada trabalho, e saber onde ele se encaixa mantém você longe de problemas Sua força é a simplicidade: para chamadas de servidor para servidor, ferramentas internas, registros de pacotes privados, trabalhos de CI e webhooks onde os dois fins já confiam um no outro e tudo passa por cima do HTTPS, é difícil de vencer Não há nada para negociar, nenhum token para atualizar, e todo cliente e biblioteca HTTP suporta isso fora da caixa Quando você controla ambos os lados e a conexão é criptografada, o auth básico é uma escolha perfeitamente razoável que continua funcionando há trinta anos.
Suas fraquezas aparecem no momento em que você sai dessa caixa Porque a credencial é enviada em cada solicitação, uma única linha de log vazada ou um proxy que registra cabeçalhos a expõe permanentemente, e girá-la significa alterá-la em todos os lugares de uma só vez Não tem conceito de escopo, então uma credencial Básica é tudo ou nada: ela não pode conceder acesso somente leitura ou expirar após uma hora E coloca uma senha real e de longa duração no fio em cada chamada, enquanto esquemas baseados em token permitem que você distribua uma credencial de curta duração e escopo restrito em vez disso.
Para autenticação voltada para o usuário, ou em qualquer lugar onde você precise de escopos, expiração ou revogação, um token de portador é o melhor modelo, e o Decodificador JWT é a ferramenta complementar para inspecionar aqueles Uma regra prática útil: alcance a autenticação básica para chamadas máquina a máquina que você controla totalmente e alcance tokens quando um terceiro, uma sessão de navegador ou um limite de permissão estiver envolvido. A tabela abaixo resume a negociação.
| Use a autenticação básica para | Prefira tokens para |
|---|---|
| Chamadas de API servidor a servidor que você controla | Sessões voltadas para o usuário |
| Ferramentas internas e registros privados | Acesso com escopo ou somente leitura |
| trabalhos de CI e webhooks sobre HTTPS | Credenciais que devem expirar |
Perguntas frequentes
O que é autenticação básica HTTP? HTTP Basic Authentication é um esquema onde um cliente envia um nome de usuário e senha com cada solicitação no cabeçalho Autorização O valor é a palavra Basic seguido pela codificação base64 de nome de usuário: senha É definido na RFC 7617 e é a maneira mais simples para um servidor verificar credenciais.
Como é construído o cabeçalho de autenticação Básico? Junte o nome de usuário e a senha com dois pontos para formar nome de usuário: senha, codifique essa string como bytes UTF-8, codifique os bytes em base64 e prefixe o resultado com Basic O cabeçalho final é Authorization: Basic seguido por esse token.
A autenticação básica é segura? Somente sobre HTTPS. Base64 é codificação, não criptografia, para que qualquer um que possa ler o cabeçalho pode decodificar a senha instantaneamente A autenticação básica não fornece confidencialidade por si só e deve sempre ser enviada através de uma conexão TLS para ser seguro.
O nome de usuário pode conter dois pontos? Não. Os primeiros dois pontos separam o nome de usuário da senha, então dois pontos no nome de usuário seriam mal interpretados como limite e dividiriam a credencial no lugar errado A senha pode conter qualquer número de dois pontos O gerador avisa se o nome de usuário tiver um.
Como decodifico um token de autenticação Básico? Pegue a parte base64 após Basic, base64-decodifique-a, e leia-a como texto UTF-8. o resultado é nome de usuário: senha, dividida nos primeiros dois pontos Cole qualquer cabeçalho de autenticação Basic no modo de decodificação tool' s para fazê-lo instantaneamente.
Qual é o equivalente de ondulação? nome de utilizador do Curl - U: password https://example.com faz a mesma coisa, porque curl constrói o cabeçalho Authorization: Basic para você a partir do valor - u. A ferramenta mostra tanto esse formulário quanto o formulário explícito do cabeçalho - H para que você possa copiar o que for adequado.
Esta ferramenta envia minhas credenciais para algum lugar? Não. A codificação e decodificação são executadas inteiramente em seu navegador com JavaScript. Seu nome de usuário e senha nunca são carregados em nenhum servidor, portanto é seguro usar com credenciais reais e ativas.
Por que usar a codificação UTF-8 para a credencial? RFC 7617 recomenda UTF-8 para que nomes de usuário e senhas não-ASCII codifiquem consistentemente entre cliente e servidor Um codificador que assume ASCII corromperia letras acentuadas ou scripts não latinos, produzindo um token que o servidor não pode corresponder.
