カスタムHTTP認証ヘッダー

124

カスタムデータをHTTP承認ヘッダーに配置することは許容できるかどうか疑問に思っていました。RESTful APIを設計しており、承認のカスタムメソッドを指定する方法が必要になる場合があります。例として、FIRE-TOKEN認証と呼びましょう。

このようなものが有効であり、仕様に従って許可されますか？ Authorization: FIRE-TOKEN 0PN5J17HBGZHT7JJ3X82:frJIUN8DYpKDtOLCwo//yllqDzg=

2番目の文字列の最初の部分（「：」の前）はAPIキーで、2番目の部分はクエリ文字列のハッシュです。

— NRaf
ソース

133

RFC2617で定義されている形式はcredentials = auth-scheme #auth-paramです。だから、フマンチュに同意すると、修正された認可スキームは次のようになると思います

Authorization: FIRE-TOKEN apikey="0PN5J17HBGZHT7JJ3X82", hash="frJIUN8DYpKDtOLCwo//yllqDzg="

どこFIRE-TOKENスキームがあり、2つのキーと値のペアは、認証パラメータです。引用符はオプションであると思いますが（p7-auth-19のApendix Bから）...

auth-param = token BWS "=" BWS ( token / quoted-string )

これは最新の標準に適合し、既に使用されており（以下を参照）、単純な拡張用のKey-Value形式を提供します（追加のパラメーターが必要な場合）。

このauth-param構文のいくつかの例をここに見ることができます...

http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-19#section-4.4

https://developers.google.com/youtube/2.0/developers_guide_protocol_clientlogin

https://developers.google.com/accounts/docs/AuthSub#WorkingAuthSub

— スタートレック
ソース

4

AmazonのシンプルなストレージAPIは、別の例を示しています。

— ビショップ

18

別のカスタムヘッダーに配置します。

標準のHTTPヘッダーをオーバーロードすると、おそらくそれよりも混乱が生じ、最小の驚きという原則に違反することになります。また、標準形式のHTTPヘッダー（などAuthorization）のみを処理できる既成のツールキットを使用するAPIクライアントプログラマーにとって、相互運用性の問題が発生する可能性もあります。

— ブライアンケリー
ソース

3

これは見た目よりも正しくするのが難しいかもしれません。fumanchuが（彼の回答へのコメントで）提供するリンクは、カスタムヘッダーを導入すると、手動でCache-Controlを正しく設定しなければならないという負担が増える理由を説明しています。

— Jon-Eric

4

また、ブラウザーを介してクロスオリジンリクエストを行っている場合、カスタムヘッダーが原因で回避できた可能性があるため、プリフライト領域にいます。特定のアプリケーションでは、これらの要求が加算されます。

— Wil Moore III

31

カスタム認証ヘッダーは巨大です。Authorization独自のカスタムスキーマを持つ仕様標準ヘッダーで十分です。さらに、@ wilmooreが示すように、プリフライトOriginリクエストを回避できます。カスタムスキームは、私が知っている最近のHTTPサーバーに干渉しません。さらに、独自のスキームを使用する場合は、自分で解析する必要があります。

— Les Hazlewood 2015

7

資格情報をAuthorizationカスタムヘッダーではなくヘッダーで送信する適切な理由は、プロキシとロガーが情報を機密情報として扱うことを知っているためです。

— エロンライト2018

15

いいえ、これはRFC 2617の「クレデンシャル」定義によると有効な生成ではありません。有効なauth-schemeを指定しますが、auth-param値は形式token "=" ( token | quoted-string )（セクション1.2を参照）である必要があり、例ではそのように「=」を使用していません。

— ふまんちゅ
ソース

1

不正解です。形式の例については、ドキュメントの5ページを参照してください。承認：基本QWxhZGRpbjpvcGVuIHNlc2FtZQ ==

— NRaf

11

それは本当だ。しかし、tools.ietf.org / html / draft-ietf-httpbis-p7-auth-16＃section-2.3.1が言うように、「b64token」表記は、既存の認証スキームとの互換性のために導入され、1回につき1回しか使用できませんしたがって、将来の拡張は不可能になるため、新しいスキームでは代わりに「auth-param」構文を使用する必要があります。カスタムヘッダーでの認証の実行に関するキャッシュの説明もご覧ください。

— フマンチュ

9

古い質問ですが、好奇心旺盛です。

信じられないかもしれませんが、この問題は20年ほど前に値をbase64エンコードされたユーザー名：パスワードとして渡すHTTP BASICで解決されました。（http://en.wikipedia.org/wiki/Basic_access_authentication#Client_sideを参照）

同じことができるので、上の例は次のようになります。

Authorization: FIRE-TOKEN MFBONUoxN0hCR1pIVDdKSjNYODI6ZnJKSVVOOERZcEtEdE9MQ3dvLy95bGxxRHpnPQ==

— マイク・マルカッチ
ソース

4

ここで使用されている表記法は既存のスキームとの互換性を保つためのものであり、新しい拡張機能には推奨されないため、この回答はお勧めしません。

— Whymarrh 2017年