カスタムデータをHTTP認証ヘッダーに入れることが可能かどうかは疑問でした。私たちはRESTful APIを設計しており、独自の認証方法を指定する方法が必要な場合があります。たとえば、認証をFIRE-TOKENとします。このようなカスタムHTTP承認ヘッダー
しまう何かが有効と仕様に応じて許可される：Authorization: FIRE-TOKEN 0PN5J17HBGZHT7JJ3X82:frJIUN8DYpKDtOLCwo//yllqDzg=
（前「：」）2番目の文字列の最初の部分は、APIキーで、第二部では、クエリ文字列のハッシュです。
カスタムヘッダーに入れます。
標準のHTTPヘッダーをオーバーロードすると、混乱が生じる可能性があり、principle of least surpriseに違反します。標準的なHTTPヘッダーの標準形式（例えば、Authorization）のみを扱うことができる、既製のツールキットを使用したいAPIクライアントプログラマーにとって、相互運用性の問題につながる可能性があります。
いいえ、それはRFC 2617の "資格情報"の定義による有効な生産ではありません。有効なauth-schemeを指定しますが、auth-paramの値はtoken "=" (token | quoted-string)（1.2節を参照）の形式でなければならず、あなたの例では "="を使用しません。
これは間違っています。形式の例については、5ページを参照してください。許可：基本QWxhZGRpbjpvcGVuIHNlc2FtZQ == – NRaf
これは本当です。しかし、http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-16#section-2.3.1のように、「 "b64token"表記は既存の認証方式との互換性のために導入されたものであり、チャレンジ/クレデンシャルごとに1回使用する必要があります。新しいスキームでは、代わりに将来の拡張が不可能になるため、代わりに "auth-param"構文を使用する必要があります。カスタムヘッダーでauthを実行することに関するキャッシュの議論も参照してください。 – fumanchu
RFC2617で定義されているフォーマットはcredentials = auth-scheme #auth-paramです。だから、fumanchuと一致して、私はFIRE-TOKENスキームであり、2つのキーと値のペアは、認証パラメータである修正認可スキームが
Authorization: FIRE-TOKEN apikey="0PN5J17HBGZHT7JJ3X82", hash="frJIUN8DYpKDtOLCwo//yllqDzg="
のように見えると思います。私は引用符が
auth-param = token BWS "=" BWS (token/quoted-string)
...（P7-AUTH-19のApendix Bから）オプションであると考えていますが、私は、これは、最新の規格に適合（下記参照）がすでに使用されている、とキーインを提供して信じています単純な拡張のための値の形式（追加のパラメータが必要な場合）
いくつかのこの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
[AmazonのシンプルストレージAPI]（http://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-auth-using-authorization-header.html）に別の例があります。 – bishop
古い私が知っている問題が、好奇心のために：
それは信じられないかもしれませんが、この問題はHTTPベーシックで約20年前に解決されました。 ■base64でエンコードされたusername：passwordの値。上記の例では、なるようにするには、同じことを行うことができ
（http://en.wikipedia.org/wiki/Basic_access_authentication#Client_sideを参照してください）：
Authorization: FIRE-TOKEN MFBONUoxN0hCR1pIVDdKSjNYODI6ZnJKSVVOOERZcEtEdE9MQ3dvLy95bGxxRHpnPQ==
私はこの回答に対してアドバイスしたいと思います。[ここでの別の回答に関するコメント]（https://stackoverflow.com/questions/7802116/custom-http-authorization-header#comment9522460_7809486）の表記は、互換性のためです既存のスキームを使用しており、新しい拡張機能には推奨されません。 – Whymarrh
これは見た目よりも権利を取得することが難しいかもしれません。 fumanchuが提供するリンク（彼の答えに対するコメント）は、カスタムヘッダーを導入するとキャッシュ制御を正しく手動で設定しなければならないという追加の負担を加える理由が説明されています。 –
また、ブラウザ経由でクロスオリジンのリクエストを行っている場合は、そうしなければ回避できたカスタムヘッダーのために、今は飛行前の領域にいます。特定のアプリケーションでは、これらの要求が加算されます。 –
カスタム認証ヘッダには巨大なものはありません。独自のカスタムスキームを持つ仕様標準の「Authorization」ヘッダは、それ以上のものでなければなりません。さらに、@ wilmooreが示すように、飛行前のOriginリクエストを避けることができます。カスタムスキームは、私が知っている合理的に現代的なHTTPサーバーに干渉することはありません。独自のスキームを使用する場合は、自分で解析する必要があります。ライブラリが競合しないようにする必要があります。 –