Ogni sviluppatore che ha integrato un'API di terze parti ha colpito lo stesso muro: i documenti dicono & quot; autentica con Basic auth, & quot; incolli la tua chiave e il tuo segreto in una richiesta e il server risponde con un flat 401 Unauthorized e nessun accenno al perché Nove volte su dieci la credenziale è stata codificata leggermente sbagliata, e non c'è nulla nell'errore che vi dica Ho costruito e consumato abbastanza API attraverso i plugin WordPress e i backend Laravel per aver sprecato una quantità imbarazzante di tempo proprio su questo, quindi ho messo un generatore auth base innanzi Toolz.dev che costruisce l'intestazione correttamente ogni volta e decodifica uno indietro quando è necessario controllare Questa è la guida ad esso e allo schema dietro di esso.
tl; dr: HTTP Basic Authentication invia un nome utente e una password come
base64(username:password)nelAuthorizationintestazione. Il Toolz generatore auth base trasforma un nome utente e una password nell'intestazione esatta, un comando curl pronto per l'esecuzione, uno snippet di recupero e il modulo URL userinfo e decodifica nuovamente i token esistenti Codifica su UTF-8 in modo che le credenziali non ASCII sopravvivano, avvisa quando il nome utente contiene due punti ed esegue interamente lato client.
Che cosa è HTTP Basic Authentication?
L'autenticazione di base HTTP è lo schema di credenziali più semplice definito dal Web. È specificato in RFC7617, che si trova in cima al quadro generale di autenticazione HTTP in RFC7235. L'idea è minima: per dimostrare chi sei, invii un Authorization intestazione il cui valore è la parola Basic, uno spazio e quindi la codifica base64 del tuo nome utente e password uniti da un singolo due punti.
Concretamente, se il tuo nome utente è admin e la tua password è secret, il client forma la stringa admin:secret, lo codifica come byte UTF-8, base64-codifica quei byte da ottenere YWRtaW46c2VjcmV0, e invia:
Authorization: Basic YWRtaW46c2VjcmV0
Quello è l'intero schema Non c'è handshake, non nonce, nessun hashing La sua semplicità è esattamente il motivo per cui è sopravvissuto: è banale da implementare su entrambe le estremità, e per gli strumenti interni, registri privati, webhook e innumerevoli API è ancora il default Il problema, ed è grande, è che la codifica è completamente reversibile, che modella tutto su come dovresti usarla.
La codifica base64 è uguale alla crittografia?
No, e questa è la cosa più importante da capire sull'autenticazione di base. Base64, definito in RFC 4648, è una codifica di trasporto Il suo scopo è quello di rappresentare dati binari o di testo utilizzando un set sicuro di 64 caratteri stampabili in modo che sopravviva all'invio attraverso sistemi che si aspettano testo Non è un cifrario, non utilizza alcuna chiave, e invertendolo ci vuole un passo Chiunque possa vedere YWRtaW46c2VjcmV0 può decodificarlo admin:secret istantaneamente, che è quello che fa questo tool's modalità di decodifica.
La conseguenza è che l'autenticazione di base fornisce da sola una riservatezza pari a zero. La credenziale viene effettivamente inviata in chiaro, semplicemente indossando un sottile travestimento. Questo è il motivo per cui l'unica regola non negoziabile dell'autenticazione di base è che deve viaggiare sempre e solo su HTTPS. TLS crittografa l'intera richiesta, inclusa la Authorization intestazione, quindi la credenziale base64 è protetta durante il trasporto Invia l'autenticazione di base su HTTP semplice e hai pubblicato la password a chiunque si trovi sul percorso di rete.
Sfrutto questo punto perché il passo base64 inganna le persone facendole credere che la credenziale sia criptata in qualche modo significativo. Non lo è. Tratta il token base64 con la stessa cura con cui tratteresti la password grezza, perché sono banalmente interconvertibili. IL strumenti online per la privacy dei dati la guida spiega perché questo strumento esegue la codifica nel browser anziché su un server, che per una credenziale live è il punto centrale.
Come viene costruita l'intestazione di Basic auth, passo dopo passo?
La costruzione è di quattro piccoli passi, e sbagliarne qualcuno leggermente produce una credenziale che fallisce silenziosamente:
- Unisciti con un colon. Formare la stringa
username:password. I due punti sono il delimitatore. - Codifica come UTF-8. Trasforma quella stringa in byte usando UTF-8. questo è importante per qualsiasi carattere non ASCII.
- Base64-codificare i byte. Applicare base standard64 per produrre il token.
- Prefisso con
Basic. Il valore finale dell'intestazione èBasicseguito dal token.
la generatore fa tutti e quattro e ti consegna l'intestazione finita Produce anche i moduli che effettivamente incolli in un terminale o in una base di codice: un comando curl utilizzando il -u flag, un comando curl con l'esplicito -H 'Authorization: Basic ...' intestazione, uno snippet di recupero, il token nudo da solo e il modulo URL userinfo https://user:pass@host. Compiti diversi vogliono forme diverse e la ridigitazione manuale della base64 è proprio il punto in cui si insinuano gli errori.
Perché il nome utente conta più della password?
C'è un'asimmetria nello schema che fa inciampare costantemente le persone, e arriva direttamente dal primo passaggio. Le credenziali sono divise sul innanzi tutto due punti. Ciò significa che il nome utente non può contenere due punti, perché il server leggerebbe i primi due punti del tuo nome utente come confine e ne consegnerebbe il resto al campo della password. La password, al contrario, può contenere tutti i due punti che desidera, poiché tutto ciò che segue i primi due punti è la password.
RFC 7617 afferma questo direttamente: l'ID utente non deve contenere due punti Questo è facile da violare senza accorgersene, soprattutto quando il nome utente è esso stesso qualcosa di strutturato come una chiave API o un identificatore a forma di email che capita di includere due punti Il generatore osserva esattamente questo e ti avverte quando il nome utente contiene due punti, perché la credenziale risultante decodificherà con la divisione nel posto sbagliato e produrrà un 401 che non ti dà alcun indizio sulla causa.
Ecco la regola in una tabella, perché vale la pena di essere inequivocabile.
| campo | Può contenere un colon? | Ragione |
|---|---|---|
| nome utente | no | I primi due punti sono il delimitatore |
| password | certo | Tutto dopo i primi due punti è la password |
Ho eseguito il debug di questo esatto fallimento in natura, dove un servizio ha emesso API & quot;usernames" che occasionalmente conteneva due punti e l'integrazione ha funzionato per la maggior parte dei clienti e ha misteriosamente fallito per alcuni L'avviso tool's avrebbe salvato quel pomeriggio.
Perché la codifica UTF-8 è importante?
Per un nome utente e una password interamente ASCII, il passaggio di codifica è invisibile; ogni carattere è un byte e base64 fa il suo dovere Nel momento in cui una credenziale contiene una lettera accentata, uno script non latino o un'emoji, la codifica dei byte diventa decisiva La RFC 7617 consiglia UTF-8 proprio in modo che client e server concordino i byte per questi caratteri.
Un codificatore ingenuo che presuppone che un carattere sia un byte o che si appoggia a un'API del browser con comportamenti legacy si corromperà café oppure пароль nei byte sbagliati, e il token base64 che produce non corrisponderà a quello che un server conforme ha calcolato dalla stessa credenziale Il risultato è un altro 401 silenzioso Questo generatore codifica la credenziale su UTF-8 a mano, quindi una password come café:naïve produce esattamente i byte che un client RFC 7617 invierebbe e il lato decodifica lo inverte fedelmente Se hai mai avuto una credenziale che funzionava per un compagno di squadra e non per un altro, un carattere non ASCII codificato in modo incoerente è un principale sospettato.
Come faccio a decodificare un token di autenticazione Basic?
Poiché la codifica è reversibile, controllare una credenziale è facile come produrne una. Prendi la parte dopo Basic , base64-decodificarlo, leggere il risultato come UTF-8, e dividere sui primi due punti Il generatore's la modalità decodifica fa questo: incolla un full Authorization: Basic ... linea, una nuda Basic ... value, o solo il token, e ti mostra il nome utente e la password che porta.
Questo è veramente utile, non solo una curiosità Quando ti viene consegnata una credenziale funzionante e ti viene chiesto di riprodurla in un nuovo ambiente, la decodifica ti dice esattamente quale nome utente e password codifica in modo da poterli impostare correttamente Quando un'integrazione fallisce, decodificare il token che stai effettivamente inviando e confrontarlo con quello che intendevi è spesso il modo più veloce per individuare uno spazio vagante, un campo sbagliato o due punti nel posto sbagliato Ed è un vivido promemoria del punto di riservatezza sopra: se puoi decodificarlo così facilmente, può farlo anche chiunque lo intercetti su HTTP semplice.
Dove il generatore si adatta agli altri strumenti
L'auth di base è uno dei numerosi strumenti di credenziali e richieste presenti sul sito che condividono lo stesso modello senza caricamento lato client. Quando il token che stai ispezionando è un token portante anziché un'auth di base, il Decodificatore JWT legge le affermazioni da un token Web JSON Quando hai bisogno di un hash anziché di una codifica, per un checksum o un digest della password, il generatore hash lo calcola Quando si desidera solo codificare o decodificare base64 arbitraria anziché una credenziale specificatamente, il convertitore base64 gestisce il caso generale E quando si esegue il debug della richiesta stessa e si desidera sapere quale client l'ha inviata, il parser agente utente legge l'intestazione User-Agent.
Per una mappa più ampia di come queste utilità di richiesta e risposta lavorano insieme, il Toolkit per sviluppatori web roundup attraversa una sessione di debug realistica e Strumenti di produttività per sviluppatori la guida copre l'assemblaggio di un set personale di loro L'auth di base raramente viene fuori in isolamento; di solito è una riga in una richiesta che stai cercando di far funzionare.
Un esempio funzionante: cablare un'integrazione API
Lasciatemi radicare questo nel compito che ho colpito di più Stai integrando un servizio di terze parti i cui documenti dicono di autenticarsi con Basic auth utilizzando una chiave API come nome utente e una password vuota, o una coppia di chiavi e segreti I documenti ti danno le credenziali ma non l'intestazione, e la prima richiesta fallisce.
Il percorso affidabile consiste nel costruire l'intestazione in modo esplicito e testarla con curl prima di scrivere una riga di codice dell'applicazione Incolla la chiave e il segreto nel generatore, copia il curl -H forma, ed eseguilo contro un endpoint noto Se il curl ha successo e il tuo codice no, il problema è nel tuo code's richiede la costruzione, non la credenziale, e hai appena tagliato lo spazio di ricerca a metà Se anche il curl fallisce, la credenziale stessa è sbagliata e la decodifica del token conferma esattamente quale campo è spento.
In un plugin WordPress ho spesso bisogno di chiamare un'API esterna da PHP, e il valore di intestazione corretto è quello che inserisco wp_remote_get via il Authorization argomento dell'intestazione. In Laravel entra nel withHeaders chiama il client HTTP oppure utilizzo il framework's withBasicAuth helper, che costruisce la stessa intestazione per me In ogni caso, avendo il noto-buono valore di intestazione dal generatore significa che sto eseguendo il debug del mio codice di richiesta contro una credenziale che ho già dimostrato funziona, piuttosto che eseguire il debug di entrambi in una volta Il caso di password vuota è dove il generatore guadagna il suo mantenimento, perché è facile dimenticarlo key: con un due punti finale è una credenziale diversa, e spesso corretta, da key solo.
L'ultima disciplina è quella di sicurezza Non incollare l'intestazione risultante in un documento condiviso, un ticket o una chat, e non inviare Basic auth su nient'altro che HTTPS Il token è la password Perché questo strumento codifica nel tuo browser e non carica mai nulla, generare la credenziale è sicuro; dove va dopo è su di te.
Quando devo usare Basic auth, e quando no?
L'auth di base non è lo strumento giusto per ogni lavoro, e sapere dove si adatta ti tiene fuori dai guai La sua forza è la semplicità: per le chiamate server-to-server, gli strumenti interni, i registri dei pacchetti privati, i lavori CI e i webhook dove le due estremità si fidano già l'una dell'altra e tutto scorre su HTTPS, è difficile da battere Non c'è niente da negoziare, nessun token da aggiornare, e ogni client e libreria HTTP lo supporta immediatamente Quando controlli entrambi i lati e la connessione è crittografata, Basic auth è una scelta perfettamente ragionevole che continua a funzionare da trent'anni.
I suoi punti deboli si manifestano nel momento in cui esci da quella casella, poiché la credenziale viene inviata su ogni richiesta, una singola riga di registro trapelata o un proxy che registra le intestazioni la espone in modo permanente, e ruotarla significa cambiarla ovunque in una volta non ha alcun concetto di ambito, quindi una credenziale Basic è tutto o niente: non può concedere l'accesso in sola lettura o scadere dopo un'ora E mette una password reale e di lunga durata sul cavo su ogni chiamata, mentre gli schemi basati su token ti consentono invece di distribuire una credenziale di breve durata e con ambito ristretto.
Per l'autenticazione rivolta all'utente o ovunque siano necessari ambiti, scadenza o revoca, un token portante è il modello migliore e il Decodificatore JWT è lo strumento complementare per ispezionare quelli Una regola pratica utile: raggiungere l'auth Basic per le chiamate machine-to-machine che si controllano completamente, e raggiungere i token quando è coinvolta una terza parte, una sessione del browser o un limite di autorizzazione La tabella seguente riassume il trade.
| Utilizzare Basic auth per | Preferisci i token per |
|---|---|
| Le chiamate API server-to-server che controlli | Sessioni rivolte all'utente |
| Strumenti interni e registri privati | Accesso con ambito o di sola lettura |
| Lavori CI e webhook su HTTPS | Credenziali che devono scadere |
Domande frequenti
Che cosa è HTTP Basic Authentication? HTTP Basic Authentication è uno schema in cui un client invia un nome utente e una password con ogni richiesta nell'intestazione Autorizzazione Il valore è la parola Basic seguita dalla codifica base64 di nome utente: password È definito nella RFC 7617 ed è il modo più semplice per un server di controllare le credenziali.
Come viene costruita l'intestazione dell'auth di Base? Unire il nome utente e la password con un singolo due punti per formare username: password, codificare quella stringa come byte UTF-8, base64-codificare i byte e prefissare il risultato con Basic L'intestazione finale è Autorizzazione: Basic seguita da quel token.
L'autenticazione di Base è sicura? Solo su HTTPS Base64 è la codifica, non la crittografia, quindi chiunque possa leggere l'intestazione può decodificare la password istantaneamente L'autenticazione di base non fornisce alcuna riservatezza da sola e deve sempre essere inviata tramite una connessione TLS per essere sicuro.
Il nome utente può contenere due punti? No. I primi due punti separano il nome utente dalla password, quindi i due punti nel nome utente verrebbero letti erroneamente come confine e dividerebbero le credenziali nel posto sbagliato La password potrebbe contenere un numero qualsiasi di due punti Il generatore ti avverte se il nome utente ne ha uno.
Come faccio a decodificare un token di autenticazione Basic? Prendi la parte base64 dopo Basic, decodificala in base64 e leggila come testo UTF-8. il risultato è nome utente: password, diviso nei primi due punti Incolla qualsiasi intestazione di autenticazione Basic nel tool' la modalità decodifica per farlo istantaneamente.
Qual è l'equivalente ricciolo? curl -u nome utente: password https://example.com fa la stessa cosa, perché curl costruisce l'intestazione Autorizzazione: Base per te dal valore - u. Lo strumento mostra sia quel modulo che il modulo di intestazione esplicito - H in modo da poter copiare a seconda di quale si adatta.
Questo strumento invia le mie credenziali da qualche parte? No. La codifica e la decodifica vengono eseguite interamente nel browser con JavaScript Il nome utente e la password non vengono mai caricati su nessun server, quindi è sicuro da usare con credenziali reali e live.
Perché utilizzare la codifica UTF-8 per le credenziali? RFC 7617 consiglia UTF-8 in modo che i nomi utente e le password non ASCII codifichino in modo coerente tra client e server Un codificatore che presuppone che ASCII corrompa le lettere accentate o gli script non latini, producendo un token che il server non può eguagliare.
