認証

認証タブは、リクエストが何者であるかを証明する方法を指定する場所です。種類を選んでフィールドを入力すると、 Echolotはリクエストを送信するたびに認証情報を付けます。 フォルダまたはワークスペースに一度認証を設定すれば、その中のすべてのリクエストで使えます。

認証情報をファイルに残さないCopy Anchor Link

どのフィールドでも{{variables}}を使えます。パスワード、トークン、キーは、キーチェーンに保存されるシークレット変数に入れ、 フィールドには{{password}}と書きます。こうすればリクエストファイルにシークレットが含まれないので、コミットできます。

認証情報のフィールドに値をそのまま入力すると、フィールドの下に警告が表示されます：ワークスペースのファイルにプレーンテキストとして保存されます。 キーチェーンに移動をクリックすると、Echolotはその値をワークスペースのシークレット変数として保存し、元の場所に{{name}}を書き込みます。

Echolotが付けた認証情報は、リクエストページに表示される場所ではマスクされます。 自動生成ヘッダーと、URLバーの下のURLプレビューが該当します。

フォルダとワークスペースから継承するCopy Anchor Link

継承がデフォルトです。継承するリクエストは、自分より上にあって認証を設定している最も近いフォルダの認証を使い、 フォルダになければワークスペースの認証を使います。使用の下には、どの認証が適用されるかがタブに表示され （例：Folder “Orders”: Bearer Token）、それを開くボタン（フォルダの認証を編集…またはワークスペースの認証を編集…）が付きます。 上のどこにも認証が設定されていなければ、リクエストは認証を送りません。

独自の認証を持つリクエストはそれを保持します。その認証タブにはワークスペースの認証の行も表示され、ワークスペースの認証と、それを開くボタンが付きます。 ボタンはワークスペースの認証…で、ワークスペースにまだ認証がなければワークスペースの認証を設定…です。 ワークスペースの認証…はコマンドパレット（⌘K）からも開けます。

多くのリクエストにまとめて認証を設定するには：

1. サイドバーでフォルダを右クリックし、フォルダ設定…を選びます。ワークスペースの場合は、リクエストの認証タブかコマンドパレットからワークスペースの認証…を選ぶか、 サイドバー下部のワークスペーススイッチャをクリックしてワークスペース設定…を選びます。
2. 認証タブを開いて種類を選びます。フォルダは継承もできますが、ワークスペースはできません。設定の下には、継承に設定されたリクエストのうち、この認証を使うものの数がタブに表示されます。
3. OAuth 2.0では、その場でサインインできます。下部のトークンバーはリクエストと同じように動作し（OAuth 2.0を参照）、この認証を継承するすべてのリクエストがそのトークンを使います。 トークンを取得は、先に認証を保存します。トークンバーにフォルダまたはワークスペース自身のトークンが表示されるのは、その認証を保存してからです。 そのため、上位の認証に属するトークンが表示されたり、消去されたりすることはありません。
4. 完了をクリックします。

Alpenglowの例では、Ordersフォルダが{{token}}を使うBearerトークンを設定していて、注文系のリクエストはすべてそれを継承します。 Auth › Sign inは、キャプチャでレスポンスから{{token}}を埋めます。

種類を選ぶCopy Anchor Link

ヘッダータブで自分で追加したAuthorizationヘッダーは、認証タブが付けるものの代わりに送信されます。

BasicCopy Anchor Link

ユーザー名とパスワードを入力します。EcholotはこれらをAuthorizationヘッダーにBase64エンコードして送ります。 AlpenglowのEcho › Basic authで試せます。

DigestCopy Anchor Link

ユーザー名とパスワードを入力します。最初の送信は認証情報なしで行われ、サーバがDigestチャレンジ付きの401を返すと、 Echolotは2回目のリクエストで一度だけそれに応答します。どちらもやり取りの中にホップとして表示されます。

BearerトークンCopy Anchor Link

トークンを入力します。通常は{{token}}です。プレフィックスのデフォルトはBearerで、別の語を求めるサーバでは変更し、トークンだけを送るには空にします。

APIキーCopy Anchor Link

キー（ヘッダーまたはパラメータの名前。デフォルトはX-API-Key）と値を入力し、追加先で送り先を選びます：ヘッダーまたはクエリ。

OAuth 2.0Copy Anchor Link

Echolotがアクセストークンを取得し、Authorization: Bearer <token>として付けます。

タブの下部のトークンバーには、トークンがあるかどうかが表示されます。トークンを取得をクリックします：

• 認可コードは、認可URLでブラウザを開きます。そこでサインインしてください。Echolotはリダイレクトを受け取り、完了するまでブラウザでサインインを完了してください…と表示します。
• デバイスコードは、コードとともに別のデバイスでサインインを表示します。開く（ページのホスト名付き）をクリックし、そこでコードを入力して承認します。 Echolotは承認を待っています…と表示して待機します。
• クライアントクレデンシャルは、トークンURLに直接問い合わせます。このグラントではトークンを取得をクリックする必要はありません。最初の送信で自動的にトークンを取得します。
• パスワード（レガシー）は、ユーザー名とパスワードをトークンURLに送ります。これもクリックは不要で、最初の送信でトークンを取得します。 これを必要とする古いAPIにだけ使ってください。パスワード自体がMacの外に出るため、このグラントは非推奨です。サーバが対応しているなら認可コードを選んでください。

Echolotは、同じく非推奨のインプリシットグラントには対応していません。インプリシットグラントを提供するサーバの多くは認可コードも提供していて、読み込んだインプリシットグラントは認可コードになります。 サーバがそれを受け付けるか確認してください。

トークンを取得すると、トークンバーにキーチェーン内のアクセストークンと表示され、種類、有効期限、自動的に更新されるかどうか、スコープも表示されます。 新しいトークンを取得は置き換え、消去は削除します。

トークンの保管と使われ方：

• トークンはキーチェーンに保存され、ワークスペースのファイルには保存されません。
• トークンは、認証を設定したリクエスト、フォルダ、ワークスペースに属し、さらに発行された環境と設定にも属します。環境を切り替えたり、トークンURL、クライアントID、スコープなど、 トークンの対象を決める設定を変更したりすると、別のトークンを使う（または取得する）ので、別の用途で発行されたトークンを送信することはありません。 フォルダからOAuthを継承するリクエストは、そのフォルダのトークンを共有します。消去は、すべての環境のトークンを削除します。
• トークンが期限切れの場合、次の送信でリフレッシュトークンを使って更新します。クライアントクレデンシャルまたはパスワードのトークンは、あらためて取得されます。 それ以外の場合、送信はこのリクエストにはOAuthトークンが必要です。まず認証タブで取得してください。または OAuthトークンの有効期限が切れ、更新できませんでした。認証タブで新しいトークンを取得してください。というメッセージで止まります。

試すには、AlpenglowのAuth › Orders with OAuth 2を送信します。デモAPIに対してクライアントクレデンシャルを使います。

詳細Copy Anchor Link

ほとんどのサーバでは不要なので、詳細の中に折りたたまれています。中に設定があると、自動的に開きます。

• 自動的に更新はデフォルトでオンです。オフにすると、期限切れのトークンをそのまま送信し、APIがどう応答するかを確認できます。クライアントクレデンシャルとパスワードでは、最初のトークンは引き続き取得されます。
• 更新URLは、更新用のエンドポイントがトークンURLと異なるサーバ向けです。空ならトークンURLを使います。
• 認可リクエスト、トークンリクエスト、更新リクエストは、標準のフィールド以上のものを求めるサーバ向けにパラメータを追加します。 たとえばGoogleのaccess_type = offline（リフレッシュトークンを返してもらうため）、Azure ADのresource、テナントやAPIバージョンなどです。 各行にはキー、値（変数が使えるので、シークレットはキーチェーンに置いたままにできます）、そしてトークンリクエストと更新リクエストでは送り先があります：ボディ、ヘッダー、またはURL。 標準のパラメータと同じ名前のパラメータは、それを置き換えます。認可リクエストのパラメータは、サインイン用のアドレスに入り、デバイスコードでは デバイス認可リクエストに入ります。stateやPKCEチャレンジを置き換えることはありません。

OAuth 1.0Copy Anchor Link

いまもOAuth 1.0を使うAPI向けです：NetSuite、MagentoとAdobe Commerce、Xのv1.1エンドポイント、JiraやConfluence Serverのアプリケーションリンクなどです。 Echolotは、すでに持っているトークンでリクエストごとに署名します。トークンを取得するための3-leggedフローは実行しません。Postmanも同様です。

1. 署名方式を選びます：HMAC-SHA1（最も一般的）、HMAC-SHA256、HMAC-SHA512、RSA-SHA1、RSA-SHA256、RSA-SHA512、またはPLAINTEXT。
2. コンシューマキーを入力し、続いてコンシューマシークレットを入力します。RSAの場合は秘密鍵を入力します（貼り付けるか、PEMファイルを選択…をクリックしてキーチェーンに直接保存します）。
3. アクセストークンを入力し、RSA以外ではトークンシークレットも入力します。トークンを取得する前のリクエストでは、空のままにします。
4. 追加先で、ヘッダー（Authorization: OAuth …、デフォルト）、URL、またはボディを選びます。ボディは、フォームのボディに署名し、ボディのないリクエストではアドレスに署名します。
5. 詳細には、レルム、コールバックURL、ベリファイア（3-leggedフローの手順を手作業で行う場合用）、oauth_version="1.0"を追加（デフォルトでオン）、 ボディのハッシュを署名に含める（oauth_body_hash。フォームでないボディ向け）があります。

各リクエストは送信時に、新しいタイムスタンプとnonceを使って、メソッド、アドレス、そのクエリ、フォームボディのフィールドを対象に署名されます。

AWS署名Copy Anchor Link

アクセスキーID、シークレットアクセスキー、リージョン（デフォルトはus-east-1）、サービス（デフォルトはexecute-api。s3、lambda、esなど）を入力します。 セッショントークンは一時的な認証情報にのみ使います。各リクエストは送信時に、実際に送信する時刻、ホスト、ボディで署名されます。

JWT BearerCopy Anchor Link

Echolotは送信のたびに新しいトークンに署名します。

1. アルゴリズムを選びます：HS256、HS384、HS512（シークレットによるHMAC）、RS256、RS384、RS512、PS256、PS384、PS512（RSA秘密鍵）、 またはES256、ES384（楕円曲線の秘密鍵）。
2. HMACではシークレットを入力します。プロバイダからBase64で渡された場合はシークレットはBase64にチェックを入れます。 秘密鍵の場合は、秘密鍵に貼り付けるか、PEMファイルを選択…をクリックします。キーはキーチェーンに直接保存され、フィールドは名前でそれを参照します。 キーはPKCS #8、PKCS #1、SEC 1のPEM形式を使えます。
3. クレームをJSONで書きます。変数を含められます：{"sub": "{{userID}}"}。
4. サーバが必要とするなら、kidなどのヘッダーフィールドを追加します。algとtypは自動で設定されます。
5. 「iat」（発行日時）を追加はデフォルトでオンです。有効期限は、指定した秒数だけ先のexpを追加します（デフォルトは300）。0なら追加しません。 JSONで自分で設定したクレームは、書いたとおりに保持されます。
6. 追加先で、ヘッダー（プレフィックス付き。デフォルトはBearer）またはクエリ（パラメータ名付き。デフォルトはtoken）を選びます。

HawkCopy Anchor Link

IDとキーを入力し、アルゴリズム（SHA-256またはSHA-1）を選び、サーバが必要とするならアプリデータ（ext）を追加します。 ペイロードのハッシュを含めるには、ボディのハッシュを署名に含めるにチェックを入れます。各リクエストは、時刻、nonce、メソッド、パス、ホスト、ポートで署名されます。

Akamai EdgeGridCopy Anchor Link

クライアントトークン、クライアントシークレット、アクセストークンを入力します。署名するヘッダーはカンマ区切りのリストで、通常は空です。 署名するボディのバイト数は、POSTボディのうちハッシュ化する量を制限します（デフォルトは131072）。

NTLMCopy Anchor Link

ユーザー名とパスワードを入力し、サーバが必要とするならドメインとワークステーションも入力します。EcholotはNTLMv2を使います。 同じ接続でサーバのチャレンジに応答し、401はやり取りの中にホップとして残ります。

NTLMはリクエストではなく接続を認証するので、HTTP/1.1が必要です。HTTPバージョンが自動のとき、EcholotはNTLMのリクエストにHTTP/1.1を使います。 HTTP/2またはHTTP/3を選んでいると、送信は拒否されます。リクエスト設定を参照してください。

認証情報は送信元のオリジンにとどまるCopy Anchor Link

リダイレクトが別のオリジン（スキーム、ホスト、ポートのいずれかが異なる）に向かう場合、Echolotはそこへ認証情報を持ち込みません。次のものを削除します：

• Authorization、Proxy-Authorization、Cookieヘッダー
• 一般的なAPIキーのヘッダー（X-API-Key、Api-Key、Apikey、X-Auth-Token、X-Access-Token、Private-Token、X-Functions-Key）、 APIキー認証が使うヘッダー、およびシークレット変数を値に含むすべてのヘッダー
• Digest、AWS署名、OAuth 1.0、Hawk、EdgeGrid、NTLMの署名と、最初のホスト用に選んだクライアント証明書

新しいホストの証明書とプロキシは、そこへ向かうホップに適用されます。リクエスト設定を参照してください。

保護された環境Copy Anchor Link

トークンを取得もリクエストを送信します。ウインドウの環境が保護されている場合、送信と同じように先に確認を求めます。 保護された環境を参照してください。