AuthorizationHTTPヘッダーをカスタマイズします

クライアントがAPIにリクエストを送信するときに、クライアントを認証する必要があります。クライアントにはAPIトークンがあり、標準Authorizationヘッダーを使用してトークンをサーバーに送信することを考えていました。

通常、このヘッダをするために使用されるBasicとDigest、認証。しかし、このヘッダーの値をカスタマイズして、カスタムauth-schemeを使用できるかどうかはわかりません。例：

Authorization: Token 1af538baa9045a84c0e889f672baf83ff24

これをお勧めしますか？または、トークンを送信するためのより良いアプローチはありますか？

Authorization:ヘッダーを使用する独自のカスタム認証スキーマを作成できます。たとえば、これがOAuthの仕組みです。

原則として、サーバーまたはプロキシが標準ヘッダーの値を理解しない場合、それらはそのままにして無視します。多くの場合、予期しない結果を引き起こす可能性のある独自のヘッダーキーを作成しています。多くのプロキシは、認識できない名前のヘッダーを削除します。

そうは言っても、Authorization:Cookieがカスタム値を運ぶように明示的に設計されているという単純な理由から、ヘッダーではなくCookieを使用してトークンを送信する方がおそらく良い考えですが、HTTPの組み込み認証メソッドの仕様では実際にはいずれにせよ、それが何を言っているのかを正確に知りたい場合は、こちらをご覧ください。

これに関するもう1つのポイントは、多くのHTTPクライアントライブラリにはダイジェストと基本認証のサポートが組み込まれていますが、ヘッダーフィールドに生の値を設定しようとすると、作業が難しくなる可能性がありますが、それらはすべてCookieを簡単にサポートします。それらの中に多かれ少なかれ任意の値を許可します。

CROSS ORIGINリクエストの場合は、以下をお読みください。

私はこの状況に直面し、最初はAuthorizationヘッダーを使用することを選択し、次の問題に直面した後、ヘッダーを削除しました。

Authorizationヘッダーはカスタムヘッダーと見なされます。したがって、Autorizationヘッダーセットを使用してクロスドメインリクエストが行われると、ブラウザは最初にプリフライトリクエストを送信します。プリフライトリクエストはOPTIONSメソッドによるHTTPリクエストであり、このリクエストはリクエストからすべてのパラメータを取り除きます。サーバーAccess-Control-Allow-Headersは、カスタムヘッダー（Authorizationヘッダー）の値を持つヘッダーで応答する必要があります。

そのため、クライアント（ブラウザー）が送信するリクエストごとに、追加のHTTPリクエスト（OPTIONS）がブラウザーによって送信されていました。これにより、APIのパフォーマンスが低下しました。これを追加するとパフォーマンスが低下するかどうかを確認する必要があります。回避策として、httpパラメーターでトークンを送信しています。これは最善の方法ではないことがわかっていますが、パフォーマンスを犠牲にすることはできませんでした。

これは少し時代遅れですが、同じ質問への答えを探している他の人がいるかもしれません。APIにとってどの保護スペースが意味をなすかを考える必要があります。たとえば、APIへのクライアントアプリケーションアクセスを識別および認証して、APIの使用を既知の登録済みクライアントアプリケーションに制限したい場合があります。この場合、あなたは使用することができますBasicクライアントIDをユーザーID、クライアント共有シークレットをパスワードとする認証方式。独自の認証スキームは必要ありません。保護スペースごとにクライアントが使用する認証スキームを明確に識別するだけです。私は保護スペースごとに1つだけを好みますが、HTTP標準では、各WWW-Authenticateヘッダー応答で複数の認証スキームと各応答で複数のWWW-Authenticateヘッダーの両方が許可されています。これは、どのオプションを使用するかをAPIクライアントにとって混乱させるでしょう。一貫性があり明確であると、APIが使用されます。

カスタムスキーム名でHTTP認証を使用しないことをお勧めします。ただし、一般的な用途があると感じた場合は、新しいスキームを定義できます。詳細については、http：//greenbytes.de/tech/webdav/draft-ietf-httpbis-p7-auth-latest.html#rfc.section.2.3を参照してください。

郵便配達員で以下を試してください：-

ヘッダーセクションの例では、私のために働いています。

承認：JWTeyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9。eyIkX18iOnsic3RyaWN0TW9kZSI6dHJ1ZSwiZ2V0dGVycyI6e30sIndhc1BvcHVsYXRlZCI6ZmFsc2UsImFjdGl2ZVBhdGhzIjp7InBhdGhzIjp7InBhc3N3b3JkIjoiaW5pdCIsImVtYWlsIjoiaW5pdCIsIl9fdiI6ImluaXQiLCJfaWQiOiJpbml0In0sInN0YXRlcyI6eyJpZ25vcmUiOnt9LCJkZWZhdWx0Ijp7fSwiaW5pdCI6eyJfX3YiOnRydWUsInBhc3N3b3JkIjp0cnVlLCJlbWFpbCI6dHJ1ZSwiX2lkIjp0cnVlfSwibW9kaWZ5Ijp7fSwicmVxdWlyZSI6e319LCJzdGF0ZU5hbWVzIjpbInJlcXVpcmUiLCJtb2RpZnkiLCJpbml0IiwiZGVmYXVsdCIsImlnbm9yZSJdfSwiZW1pdHRlciI6eyJkb21haW4iOm51bGwsIl9ldmVudHMiOnt9LCJfZXZlbnRzQ291bnQiOjAsIl9tYXhMaXN0ZW5lcnMiOjB9fSwiaXNOZXciOmZhbHNlLCJfZG9jIjp7Il9fdiI6MCwicGFzc3dvcmQiOiIkMmEkMTAkdTAybWNnWHFjWVQvdE41MlkzZ2l3dVROd3ZMWW9ZTlFXejlUcThyaDIwR09IMlhHY3haZWUiLCJlbWFpbCI6Im1hZGFuLmRhbGUxQGdtYWlsLmNvbSIsIl9pZCI6IjU5MjEzYzYyYWM2ODZlMGMyNzI2MjgzMiJ9LCJfcHJlcyI6eyIkX19vcmlnaW5hbF9zYXZlIjpbbnVsbCxudWxsLG51bGxdLCIkX19vcmlnaW5hbF92YWxpZGF0ZSI6W251bGxdLCIkX19vcmlnaW5hbF9yZW1vdmUiOltudWxsXX0sIl9wb3N0cyI6eyIkX19vcmlnaW5hbF9zYXZlIjpbXSwiJF9fb3JpZ2luYWxfdmFsaWRhdGUiOltdLCIkX19vcmlnaW5hbF9yZW1vdmUiOltdfSwiaWF0IjoxNDk1MzUwNzA5LCJleHAiOjE0OTUzNjA3ODl9.BkyB0LjKB4FIsCtnM5FcpcBLvKed_j7rCCxZddwiYnU