基本的なHTTPおよびベアラートークン認証


115

現在、開発環境用にHTTP-Basicで保護されたREST-APIを開発しています。実際の認証はトークンを介して行われるので、2つの認証ヘッダーを送信する方法を理解しようとしています。

私はこれを試しました:

curl -i http://dev.myapp.com/api/users \
  -H "Authorization: Basic Ym9zY236Ym9zY28=" \
  -H "Authorization: Bearer mytoken123"

たとえば、IPのHTTP認証を無効にすることもできますが、通常は動的IPを使用してさまざまな環境で作業しているため、これは適切なソリューションではありません。だから私は何かが足りないのですか?


2
開発サーバーはHTTP Basicで保護されているため、HTTP Basicで認証する必要があります。APIにはトークンベースの認証が必要です。しかし、私はカールを使用してAPIをテストしているので、両方の認証ヘッダーを送信する方法が必要です。したがって、最初の1つ(基本)はHTTP Basicを渡し、2番目の1つ(トークン)はアプリケーションへの認証を行います。そして、はい、それは私自身の創造物です。
Azngeek 2014年

1
あなたはこれを理解したことがありますか?賞金を追加します
アダムウェイト2014年

4
こんにちはアダム、残念ながらそうではありません。トークンの認証ヘッダーを標準ヘッダーではない「x-auth」に変更することで、認証の動作を変更しました。
Azngeek 14年

1
私のnginxサーバーは2つのAuthorizationヘッダーさえも受け入れません。を返します400 Bad request。ばか。
Rudie

1
APIトークンにカスタムヘッダーを使用することの何が問題になっていますか?ここの人々が開発/ステージングサーバーをのぞき見から遠ざけるためにHTTP Basic Authを使用して「スクラップ」した理由はわかりません。
Sunil D.

回答:


68

これを試して、URLで基本認証をプッシュします。

curl -i http://username:password@dev.myapp.com/api/users -H "Authorization: Bearer mytoken123"
               ^^^^^^^^^^^^^^^^^^

上記の1つが機能しない場合は、それとは何の関係もありません。したがって、以下の代替案を試してください。

トークンを別の名前で渡すことができます。アプリケーションからの承認を処理しているからです。したがって、この柔軟性をこの特別な目的に簡単に使用できます。

curl -i http://dev.myapp.com/api/users \
  -H "Authorization: Basic Ym9zY236Ym9zY28=" \
  -H "Application-Authorization: mytoken123"

ヘッダーをに変更したことに注意してくださいApplication-Authorization。したがって、アプリケーションからそのヘッダーの下でトークンをキャッチし、必要な処理を実行します。

あなたが行うことができますもう一つは、渡すこと、であるtokenを通じてPOSTパラメータとサーバ側からのパラメータの値をつかみます。たとえば、curl postパラメータを使用してトークンを渡す場合:

-d "auth-token=mytoken123"

1
こんにちはSabuj、問題はユーザー名とパスワードを渡す方法ではなく、複数の認証ヘッダーが機能しないことです。仕様(ietf.org/rfc/rfc2617.txt)を見ると、これが可能であることがわかります。しかし、「ユーザーエージェントは、理解する最強の認証方式でチャレンジの1つを使用し、そのチャレンジに基づいてユーザーから資格情報を要求することを選択する必要があります。」ので、2日前に書いたように、非標準のアーキテクチャを扱うときに絶対に問題ない非標準ヘッダーへのトークン
Azngeek

5
@Azngeek Curlは、タスクを実行するときに両方の認証ヘッダーを送信します。サーバー側から処理する必要があります。両方のヘッダーに-vparamを付けてcurlコマンドを実行するだけです。Authorization: Basic Ym9zY236Ym9zY28=, Authorization: Bearer mytoken123リクエストヘッダーで送信することがわかります。サーバー側から確認すると、このようにAuthorizationヘッダーAuthorization: Basic Ym9zY236Ym9zY28=, Bearer mytoken123がコンマで区切られていることがわかります。だから、私はあなたに代替案を提案するべきですが。
Sabuj Hassan 14年

34

標準(https://tools.ietf.org/html/rfc6750)は、以下を使用できると述べています

  • フォームエンコードされた本文パラメーター:承認:Bearer mytoken123
  • URIクエリパラメータ:access_token = mytoken123

そのため、URIを使用して多くのベアラートークンを渡すことは可能ですが、これはお勧めできません(標準のセクション5を参照)。


4

間にnginxなどのリバースプロキシを使用している場合は、などのカスタムトークンを定義できますX-API-Token

nginxでは、上流のプロキシ(残りのAPI)がauthになるように書き換えます。

proxy_set_header Authorization $http_x_api_token;

... nginxは元のAuthorizationヘッダーを使用してHTTP AUthをチェックできます。


3

同様の問題がありました-デバイスでデバイスとユーザーを認証します。Cookieヘッダーと一緒にAuthorization: Bearer...ヘッダーを使用しました。


なぜ反対票かは明らかではない。私は関連する問題の答えを探しているこの質問に出くわしました-これが私がそれを解決した方法です。Cookieヘッダは、既に頻繁に認証に使用されます。
Iiridayn

2

curl --anyauth

curlにそれ自体で認証方法を理解し、リモートサイトがサポートすると主張している最も安全な方法を使用するように指示します。これは、最初に要求を実行し、応答ヘッダーをチェックすることによって行われます。そのため、追加のネットワークラウンドトリップが発生する可能性があります。これは、特定の認証方法を設定する代わりに使用されます。これは、-basic、-digest、-ntlm、および--negotiateで実行できます。


1

開発サーバーでAPIをテストするための別のソリューションがあります。

  • HTTP Basic AuthenticationWebルートのみに設定
  • すべてのAPIルートを認証から解放する

Webサーバーの構成は次のようにnginxなりますLaravel

    location /api {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location / {
        try_files $uri $uri/ /index.php?$query_string;

        auth_basic "Enter password";
        auth_basic_user_file /path/to/.htpasswd;
    }

Authorization: Bearer Webクローラーやその他の不要な訪問者から開発サーバーを守る役割を果たします。


0

nginxを使用すると、次のように両方のトークンを送信できます(標準に違反している場合でも)。

Authorization: Basic basic-token,Bearer bearer-token

これは、基本的なトークンが最初である限り機能します-nginxはそれをアプリケーションサーバーに正常に転送します。

次に、アプリケーションが上記の文字列からBearerを適切に抽出できることを確認する必要があります。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.