カスタムHTTP認証ヘッダー
HTTP認証ヘッダーにカスタムデータを含めることが許容されるかどうか疑問に思っていました。 RESTful APIを設計していますが、カスタム認証方法を指定する方法が必要になる場合があります。例として、それをFIRE-TOKEN認証と呼びましょう。
このような何かが有効であり、仕様に従って許可されます：Authorization: FIRE-TOKEN 0PN5J17HBGZHT7JJ3X82:frJIUN8DYpKDtOLCwo//yllqDzg=
2番目の文字列の最初の部分（「：」の前）はAPIキーで、2番目の部分はクエリ文字列のハッシュです。
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
別のカスタムヘッダーに配置します。
標準のHTTPヘッダーのオーバーロードは、おそらく価値以上の混乱を引き起こし、 最小限の驚きの原則 に違反します。また、一般的なHTTPヘッダーの標準形式（Authorizationなど）のみを処理できる既製のツールキットを使用するAPIクライアントプログラマーの相互運用性の問題につながる可能性があります。
いいえ、それは RFC 2617 の「信任状」定義によると、有効なプロダクションではありません。有効なauth-schemeを指定しますが、auth-param値はtoken "=" ( token | quoted-string )（セクション1.2を参照）の形式である必要があり、例ではそのように「=」を使用していません。
私が知っている古い質問ですが、好奇心のために：
信じられないかもしれませんが、この問題は、約20年前にHTTP BASICで解決されました。HTTPBASICは、base64エンコードのusername：passwordとして値を渡します。 （ http://en.wikipedia.org/wiki/Basic_access_authentication#Client_side を参照）
同じことができ、上の例は次のようになります。
Authorization: FIRE-TOKEN MFBONUoxN0hCR1pIVDdKSjNYODI6ZnJKSVVOOERZcEtEdE9MQ3dvLy95bGxxRHpnPQ==