web-dev-qa-db-ja.com

カスタム認証ヘッダー

スタックオーバーフローでこの質問に十分なコンテンツがあることはわかっていますが、私の主題は他の主題と同じではありません。 （ちょっと同じですが等しくありません）

私は自分がしていることについてコミュニティの考えを聞き、どこかで改善できるかどうかを見たいです。

現在、ログインEndPointには基本認証を使用しています。これは、複雑さを必要とせず、httpsを介する必要がないため、問題ありません。

例：

GET-/ api/login

承認：基本的なBASE64String（username：password）

一部のエンドポイントでは、トークンにリソースへのアクセスを許可する必要があります。これらのトークンは、ヘッダーとHttps-Securedを介して送信しています。

問題は、これらの承認を行う従来の方法を使用していないことです。以下の例：

例1：

GET-/ api/hardware/{PUBLIC_TOKEN}/getMe

Authorization-Hardware：PRIVATE_TOKEN

このEndPointはAuthorization-Hardwareヘッダーを必要としませんが、含まれている場合、APIによってさらに多くのことが行われます。 （ここでは関係ありません）

例2：

GET-/ api/login/{id}

Authorization-Person：SER_TOKEN

それ以外の場合、このEndPointは、リソースにアクセスするためのAuthorization-Personヘッダーとユーザートークンを含めて必要です。 （トークンの生成方法はここでは関係ありません）

APIエンドポイントにアクセスするには、HTTPSリクエストが必要です。

上記のカスタムヘッダーとエンドポイントに任意の名前を付けましたが、これは私の承認スキーマとは何かを示すためのものです。名前が元の名前と一致していません。そのため、スキーマの単なるフォーカスを気にしないでください。

私の質問は次のとおりです。従来の方法に従わないのはとても悪いことですか？カスタム認証ヘッダーの作成は、どういうわけか悪いのです（もしそうなら、それはなぜですか？）。

私はこの方法が認可とトークンを渡す安全な方法を与える方が簡単だと思います。これらのトークンはすべてプラットフォームで再び生成できます。

多くのデバイスとモバイルアプリケーションはすでにこのスキーマを使用していますが、すべて開発環境下にあり、まだ本番環境にはありません。私の恐れは、これを行う従来とは異なる方法が将来的にAPIのユーザーに影響を与える可能性があることです。コミュニティの考えが私がこれを改善するのに役立つことを願っています。

編集：2017年3月26日

カスタムヘッダーがあり、その値を取得したい場合よりも、複数の認証が必要な場合にヘッダーからフェッチするのが難しいため、プロトコルに記載されている方法で実装する方が良いか、なぜ実装するのかを知りたいです。

プロトコルに従って、次のような承認ヘッダーを使用する必要があります。

Authorization: <type> <value>

例：

GET-/ api/login/{id}

承認：ユーザーSER_TOKEN

しかし、その値をフェッチすると文字列が返されるか、例の場合はユーザートークンが返されるため、私はこれに従って何が得られるかわかりません。

カスタムヘッダーを使用すると、トークンを簡単に検証できます。複数の承認は、プロトコルの方法に従っても頭痛を与える可能性があります。

apihttphttp-headersauthorizationrestful-authentication
14
Igor Morse

TL; DR Authorizationなどの一部のヘッダー名には、キャッシュおよびプロキシとクライアントの処理に関する特別なルールがあります。すべてのプロキシとクライアントをすべて変更しない限り、カスタムヘッダー名は特別な動作をしません。

RFC7234 で定義されている共通のAuthorization: <type> <value>ヘッダーを使用する目的は、これらのヘッダーの処理をネイティブに実装するクライアントとHTTPプロキシが正しく動作するようにすることです。

RFC7234のセクション4.2は次のように述べています。

リクエストを転送するプロキシは、そのリクエストの認証フィールドを変更してはいけません。 HTTPキャッシュによるAuthorizationフィールドの処理に関する詳細と要件については、[RFC7234]のセクション3.2を参照してください。

プロキシは、他のAuthorization-*ヘッダーを変更、省略、記録、またはキャッシュする可能性があります。

RFC7234、セクション3.2 は、リクエスト/レスポンスAuthorizationヘッダーをキャッシュしてはならないことを示しています（特定の状況を除く）。

RFC7235、セクション5.1.2、ポイント7 さらに、Authorization以外のヘッダーを使用する新しい認証スキームについてこれは言います：

したがって、Authorizationヘッダーフィールドに資格情報を保持しないことを選択する新しい認証スキーム（たとえば、新しく定義されたヘッダーフィールドを使用）は、いずれかのCache-Control要求ディレクティブ（たとえば、「no-ストア」、[RFC7234]のセクション5.2.1.5）または応答ディレクティブ（「プライベート」など）。

それで、あなたは何をすべきですか...？システムの両端を完全にコントローラーで制御する場合、,文字を避けて、1つ以上のトークンタイプの任意の組み合わせをカバーする複数のパラメーターを持つ新しいタイプ値を定義することは不合理ではありません。

Authorization: MyAuth User=USER_TOKEN/Hardware=HWTOKEN/Person=PERSONTOKEN/Basic=...

代替案は、サーバーとクライアントの実装により依存し、,を複数のヘッダーの代替バージョンリスト形式として使用します。

Authorization: User USER_TOKEN, Hardware=HWTOKEN, Person=PERSONTOKEN, Basic=...

これは、サーバーとクライアントに応じて、次のように扱われます。

Authorization: User USER_TOKEN
Authorization: Hardware HWTOKEN
Authorization: Person PERSONTOKEN
Authorization: Basic ...

ここでの問題は、「[〜＃〜]かもしれない[〜＃〜]」（強調の多く）が同じように扱われることです。 ApacheとNGINXのさまざまなバージョンがこれを一貫して処理しないこと、および古いHTTP RFCが意図された動作について非常に不明確であることが示唆されています。

23
robbat2