web-dev-qa-db-ja.com

カスタムHTTP認証ヘッダー

HTTP認証ヘッダーにカスタムデータを含めることが許容されるかどうか疑問に思っていました。 RESTful APIを設計していますが、カスタム認証方法を指定する方法が必要になる場合があります。例として、それをFIRE-TOKEN認証と呼びましょう。

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

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

httprestheaderauthorization
120
NRaf

RFC2617 で定義されている形式はcredentials = auth-scheme #auth-paramです。したがって、fumanchuに同意すると、修正された承認スキームは次のようになります。

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

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

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

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

この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

129
StarTrekRedneck

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

標準のHTTPヘッダーのオーバーロードは、おそらく価値以上の混乱を引き起こし、 最小限の驚きの原則 に違反します。また、一般的なHTTPヘッダーの標準形式（Authorizationなど）のみを処理できる既製のツールキットを使用するAPIクライアントプログラマーの相互運用性の問題につながる可能性があります。

22
Brian Kelly

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

15
fumanchu

私が知っている古い質問ですが、好奇心のために：

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

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

Authorization: FIRE-TOKEN MFBONUoxN0hCR1pIVDdKSjNYODI6ZnJKSVVOOERZcEtEdE9MQ3dvLy95bGxxRHpnPQ==
9
Mike Marcacci