サードパーティの API を統合したすべての開発者は同じ壁にぶつかりました。ドキュメントでは " と書かれています。基本認証と引用で認証します。キーとシークレットをリクエストに貼り付けると、サーバーがフラットで応答します 401 Unauthorized そして、その理由についてのヒントはありません。 10 回中 9 回は、資格情報がわずかに間違ってエンコードされており、エラーにはそれを伝えるものは何もありません。私は、WordPress プラグインと Laravel バックエンド全体で十分な API を構築して消費し、まさにこれに恥ずかしい時間を無駄にしたので、a を入れました 基本的なauthジェネレータ で Toolz.dev これは、ヘッダーを毎回正しく構築し、確認する必要があるときにヘッダーをデコードします。これがヘッダーとその背後にあるスキームのガイドです。
tl;dr: HTTP Basic Authentication は、ユーザー名とパスワードを次のように送信します
base64(username:password)中にAuthorizationヘッダー。 The Toolz 基本的なauthジェネレータ ユーザー名とパスワードを正確なヘッダー、すぐに実行できる curl コマンド、フェッチ スニペット、URL userinfo フォームに変換し、既存のトークンをデコードします。 UTF-8 上でエンコードするため、非 ASCII 資格情報は存続し、ユーザー名にコロンが含まれている場合に警告し、完全にクライアント側で実行されます。
HTTP Basic Authenticationとは?
HTTP Basic Authentication は、Web が定義する最も単純な資格情報スキームです。 で指定されています RFC 7617、一般的なHTTP認証フレームワークの上に座っています RFC 7235。考え方は最小限です。自分が誰であるかを証明するために、あなたは を送信します Authorization 値が単語であるヘッダー Basic、スペース、そして単一のコロンで結合されたユーザー名とパスワードの base64 エンコーディング。
具体的には、ユーザー名がそうであれば admin そしてあなたのパスワードは secret、クライアントは文字列を形成します admin:secret、UTF-8 バイトとしてエンコードし、base64-取得するそれらのバイトをエンコードします YWRtaW46c2VjcmV0、および送信します:
Authorization: Basic YWRtaW46c2VjcmV0
それがスキーム全体です ハンドシェイクもノンスもハッシュもありません そのシンプルさがまさに生き残った理由です 両端に実装するのは些細なことです 内部ツール、プライベートレジストリ、Webフック、無数のAPIでは まだデフォルトのキャッチです そしてそれは大きな問題ですが エンコーディングは完全に可逆的であり、それがそれをどのように使用すべきかについてのすべてを形作ります。
base64 のエンコーディングは暗号化と同じですか?
いいえ、そしてこれは Basic auth について理解すべき唯一の最も重要なことです。 で定義された Base64 RFC 4648、はトランスポート符号化である。 64 個の印刷可能な文字からなる安全なセットを使用してバイナリまたはテキストデータを表現し、テキストを期待するシステムを通じて送信されても生き残ることを目的としている。 暗号ではなく、キーを使用せず、反転すると1 つのステップが取れる人 YWRtaW46c2VjcmV0 にデコードできます admin:secret 即座に、これがこのツール' のデコード モードの機能です。
その結果、Basic 認証はそれ自体で機密性をゼロにすることになります。 credential は、薄い偽装をしているだけで、事実上クリアで送信されます。 basic auth の唯一の譲れないルールが、HTTPS 経由でのみ移動しなければならないという理由です。 TLS は、を含むリクエスト全体を暗号化します Authorization ヘッダーなので、base64 クレデンシャルは転送中に保護されます。 basic auth をプレーン HTTP で送信すると、ネットワーク パス上の誰にでもパスワードを公開できます。
私はbase64 ステップが、資格情報が何らかの意味のある方法でスクランブルされていると考えるように人々をだますので、この点を苦労しています。 それはそうではありません。 base64 トークンを、生のパスワードを扱うのと同じ注意を払って扱います。なぜなら、それらは自明に相互変換可能だからです。 データプライバシー オンラインツール このツールがサーバー上ではなくブラウザーでエンコードを行う理由については、ガイドで説明します。ライブ資格情報については、これが重要な点です。
Basic auth ヘッダーは段階的にどのように構築されますか?
構築は4 つの小さなステップで、それらのいずれかを少し間違えると、サイレントに失敗する資格情報が生成されます:
- コロンで結合します. 文字列を形成します
username:password. コロン は 区切り. - UTF-8 としてエンコードします. UTF-8 を使用してその文字列をバイトに変換します。これは、ASCII 以外の文字にとって重要です。
- Base64-バイトをエンコードします. 標準のbase64 を適用してトークンを生成します.
- を接頭辞とする
Basic。 最終的なヘッダー値はBasicトークンが続きます.
ザ・ 発電機 4 つすべてを実行し、完成したヘッダーを渡します。また、ターミナルまたはコードベースに実際に貼り付けるフォーム、つまり、を使用して curl コマンドも生成します -u フラグ、明示的なカール コマンド -H 'Authorization: Basic ...' ヘッダー、フェッチ スニペット、それ自体のベア トークン、および URL userinfo フォーム https://user:pass@host。 さまざまなタスクは、さまざまなフォームを望んで, 手でベース64 を再入力すると、正確に間違いが忍び寄る場所です。
パスワードよりもユーザー名が重要なのはなぜですか?
スキームには、人々を常につまずかせる非対称性が 1 つあり、それはステップ 1 から直接得られます。資格情報は で分割されます 先に コロン。つまり、ユーザー名にはコロンを含めることはできません。サーバーはユーザー名の最初のコロンを境界として読み取り、残りのコロンをパスワード フィールドに渡すことになるからです。対照的に、パスワードには、最初のコロン以降はすべてパスワードであるため、好きなだけコロンを含めることができます。
RFC 7617 はこれを直接述べています: user-id にはコロンが含まれてはなりません これは特にユーザー名がそれ自体APIキーやたまたまコロンを含む電子メール型の識別子のような構造化されたものである場合に気付かずに簡単に違反することを監視しますジェネレーターはユーザー名にコロンが含まれていると警告します、なぜなら結果として得られる資格情報は間違った場所に分割されてデコードされ、原因についての手がかりを与えない401 を生成するからです。
表内のルールは次のとおりです。これは明確にする価値があるからです。
| フィールド | コロンが含まれている可能性がありますか? | 理由 |
|---|---|---|
| ユーザー名 | いやー | 最初のコロンが区切り文字です |
| パスワード | はいって | 最初のコロン以降のすべてがパスワードです |
私は、サービスが API "usernames" を発行し、時折コロンを含む統合がほとんどの顧客のために機能し、少数のために不思議に失敗したこの正確な障害を、野生でデバッグしました。 tool's の警告は、その日の午後に保存されたでしょう。
なぜUTF-8 のエンコーディングが重要なのでしょうか?
all-asciiのユーザー名およびパスワードの場合、エンコーディングのステップは目に見えない; すべての文字は1 バイトであり、base64 はそのことを行う. credentialがアクセント付き文字、非ラテン文字、または絵文字を含む瞬間、バイトエンコーディングは決定的になる.RFC 7617 は、クライアントとサーバがこれらの文字のバイトについて合意するように、正確にUTF-8 を推奨している。
1 文字が 1 バイトであると仮定する単純なエンコーダ、または従来の動作でブラウザ API に依存する単純なエンコーダが破損します café や пароль 間違ったバイトに、そしてそれが生成するbase64 トークンは、準拠したサーバーが同じ資格情報から計算したものと一致しません。 結果は別のサイレント401 です。 このジェネレータは、UTF-8 を介して資格情報を手でエンコードするため、次のようなパスワードです café:naïve RFC 7617 クライアントが送信するバイトを正確に生成し、デコード側がそれを忠実に反転します。あるチームメイトには有効で、別のチームメイトには有効ではない資格情報を持っていた場合、一貫性なくエンコードされた非 ASCII 文字が主な容疑者となります。
Basic auth トークンをデコードするにはどうすればよいですか?
エンコーディングは可逆的であるため、資格情報の確認は、資格情報を生成するのと同じくらい簡単です。 の後に部分を取ります Basic 、base64-decodeして、その結果をUTF-8 と読み、最初のコロンで分割する。 としている ジェネレーター' s デコード モードでは次のことが行われます。フルペーストします Authorization: Basic ... ライン、むき出し Basic ... 値、またはトークンだけを表示すると、それが持つユーザー名とパスワードが表示されます。
これは純粋に役に立ちます単なる好奇心ではありません作業用の資格情報を渡され新しい環境で再現するように頼まれたときデコードは正確にどのユーザー名とパスワードをエンコードするか教えてくれるので正しく設定できます統合が失敗したとき実際に送信しているトークンをデコードして意図したものと比較することはしばしば迷走スペース、間違ったフィールド、間違った場所のコロンを見つけるための最速の方法ですそしてそれは上の機密性のポイントを鮮明に思い出させるものです:これで簡単にデコードできるなら、普通のHTTPで傍受する人は誰でもできるのです。
ジェネレーターが他のツールと適合する場所
Basic auth は、同じクライアント側のノーアップロード モデルを共有するサイト上のいくつかの資格情報およびリクエスト ツールの 1 つです。検査しているトークンが Basic auth ではなくベアラー トークンである場合、 JWT デコーダ JSON Web トークンからクレームを読み出します。エンコーディングではなくハッシュが必要な場合、チェックサムまたはパスワード ダイジェストの場合、 ハッシュジェネレータ 計算します。 credential を具体的にエンコードするか、または任意の base64 をデコードするだけの場合、 base64 コンバーター 一般的なケースを処理します。そして、リクエスト自体をデバッグしていて、それを送信したクライアントを知りたいときは、 ユーザーエージェントパーサー user-agent ヘッダーを読み取ります.
これらのリクエストとレスポンスのユーティリティがどのように連携するかについてのより広範なマップについては、次のようになります Web 開発者ツールキット ラウンドアップでは、現実的なデバッグ セッションについて説明します 開発者の生産性向上ツール ガイドはそれらの個人的なセットを組み立てることをカバーします。 basic auth はめったに孤立して出て来ません; それは通常あなたが仕事を作ろうとしている要求の1 行です。
有効な例: API 統合の配線
私が最もヒットしたタスクでこれを接地させてください。あなたは、API キーをユーザー名と空のパスワード、またはキーとシークレットのペアとして使用して、Basic 認証を使用して認証するとドキュメントが言うサードパーティ サービスを統合しています。ドキュメントは資格情報を提供しますが、ヘッダーは与えません。最初のリクエストは失敗します。
信頼できるパスは、アプリケーションコードの行を書く前に、ヘッダーを明示的にビルドし、curlでテストすることです。 にキーとシークレットを貼り付けます 発電機、 をコピーします curl -H フォームし、既知のエンドポイントに対して実行します。 curl が成功し、コードが成功しない場合、問題は code' のリクエスト構築にあり、資格情報ではなく、検索スペースを半分にカットしただけです。 curl も失敗すると、資格情報自体が間違っており、トークンをデコードすると、どのフィールドがオフになっているかが正確に確認されます。
WordPress プラグインでは、PHP から外部 API を呼び出す必要があることがよくありますが、正しいヘッダー値はフィードされるものです wp_remote_get via the Authorization ヘッダ引数. Laravelでは, に入ります. withHeaders HTTP クライアントを呼び出すか、フレームワーク & #39;s を使用します withBasicAuth helper, which builds the same header for me.いずれにせよ、ジェネレーターからknown-goodヘッダー値を持つことは、両方を一度にデバッグするのではなく、すでに証明した資格情報に対してリクエストコードをデバッグしていることを忘れやすいため、empty-passwordケースはジェネレーターがキープを獲得するケースです key: 後続のコロンを使用すると、別の、多くの場合正しい資格情報になります key 一人で.
最後の規律はセキュリティです 結果のヘッダーを共有ドキュメント、チケット、チャットに貼り付けず、HTTPS以外のものではBasic authを送信しないでください トークンはパスワードです このツールはブラウザでエンコードされ、何もアップロードしないため、資格情報の生成は安全です; それが後に行く場所はあなたの上にあります。
Basic auth はいつ使うべきで、いつ使わないべきですか?
Basic auth はすべてのジョブに適したツールではなく、どこに当てはまるかを知っていればトラブルを回避できます。その強みはシンプルさです。サーバー間の通話、内部ツール、プライベート パッケージ レジストリ、CI ジョブ、および 2 つのエンドがすでに相互に信頼し、すべてが HTTPS 経由で実行されている Webhook の場合、これに勝るものはありません。ネゴシエートするものも、更新するトークンもなく、すべての HTTP クライアントとライブラリがすぐにサポートします。両側を制御し、接続が暗号化されると、Basic auth は 30 年間機能し続ける完全に合理的な選択です。
その弱点は、そのボックスの外に出た瞬間に現れます 資格情報はすべての要求で送信されるため、単一の漏洩ログ行またはヘッダーを記録するプロキシは永久にそれを公開し、回転させることは、一度にどこでも変更できる範囲の概念がないため、基本的な資格情報はオールオアナッシングです: 読み取り専用アクセスを許可したり、1 時間後に期限切れになったりすることはできません そして、すべての通話でワイヤーに実際の長寿命のパスワードを入力しますが、トークンベースのスキームでは、代わりに短寿命で狭い範囲の資格情報を配布できます。
ユーザー向け認証、またはスコープ、有効期限、または失効が必要な場所であればどこでも、ベアラー トークンの方が優れたモデルです JWT デコーダ は、これらを検査するためのコンパニオンツールです。 便利な経験則: reach for Basic auth for machine-to-machine calls you full control, and reach for tokens when a third party, a browser session, or apermission boundary is involved.以下の表は、取引をまとめたものです。
| Basic auth for を使用します | のトークンを優先します |
|---|---|
| サーバー間 API 呼び出しを制御します | ユーザー向けセッション |
| 内部ツールとプライベート レジストリ | スコープ付きまたは読み取り専用アクセス |
| HTTPS を介した CI ジョブと Webhook | 有効期限が切れる必要がある資格情報 |
よくある質問
HTTP Basic Authenticationとは? HTTP Basic Authentication は、クライアントが Authorization ヘッダーの各リクエストとともにユーザー名とパスワードを送信するスキームです。値は、Basic という単語と、その後に username:password の base64 エンコーディングが続きます。 RFC 7617 で定義されており、サーバーが資格情報を確認する最も簡単な方法です。
Basic auth ヘッダーはどのように構築されますか? ユーザー名とパスワードを単一のコロンで結合して username:password を形成し、その文字列を UTF-8 バイトとしてエンコードし、バイトを base64-encode し、結果の先頭に Basic を付けます。最後のヘッダーは Authorization:Basic で、その後にトークンが続きます。
Basic認証は安全ですか? HTTPS経由のみ。 base64 は暗号化ではなくエンコードであるため、ヘッダーを読み取ることができる人は誰でもパスワードを即座にデコードできます。 basic auth はそれ自体で機密性を保証せず、安全であるためには常に TLS 接続経由で送信する必要があります。
ユーザー名にコロンを含めることはできますか? いいえ 最初のコロンがユーザー名とパスワードを区切っているので、ユーザー名のコロンが境界として読み間違えられ、資格情報が間違った場所に分割されてしまいます パスワードには任意の数のコロンが含まれている可能性があります ジェネレータは、ユーザー名にコロンがあるかどうかを警告します。
Basic auth トークンをデコードするにはどうすればよいですか? Basic の後に base64 の部分を取り、base64-decode して、UTF-8 テキストとして読みます。 username:password という結果になり、最初のコロンで分割されます。 tool's デコード モードに任意の Basic 認証ヘッダーを貼り付けて、即座に実行します。
カール相当とは? curl -u ユーザ名:password https://example.com 同じことを行います。 curl は -u 値から Authorization: Basic ヘッダーを構築します。ツールにはその形式と明示的な -H ヘッダー形式の両方が表示されるため、どちらに当てはまるかをコピーできます。
このツールはどこにでも資格情報を送信しますか? いいえ エンコードとデコードは完全に JavaScript を使用してブラウザーで実行されます。ユーザー名とパスワードはどのサーバーにもアップロードされないため、実際のライブ認証情報を使用しても安全に使用できます。
なぜ資格情報に UTF-8 エンコーディングを使用するのですか? RFC 7617 では、クライアントとサーバーの間で非 ASCII ユーザー名とパスワードが一貫してエンコードされるように UTF-8 を推奨しています。 ASCII がアクセント付き文字や非ラテン文字を壊し、サーバーが一致できないトークンを生成すると想定するエンコーダ。
