Authorization:

Authorization: ヘッダー (HTTP)

[5] Authorization: ヘッダーは、 HTTP認証のためのクライアントcredentials を指定するものです。

仕様書

意味

[6] Authorization: ヘッダーは、 利用者エージェント起源鯖において認証するためのもので、 要求されている資源保護空間における利用者エージェント認証情報を含む credentials を指定するものです >>3

構文

[410] Authorization: ヘッダーの値は credentials です >>3, >>409, >>413

  1. credentials
[8] 複数の credentials を同時に指定する方法はありません。
credentialsauth-param も参照。

文脈

[7] Authorization: ヘッダーは通常 401 応答を受け取った後の要求で使いますが、 必ずしもそうでなくても構いません >>3

[48] 通常 Webブラウザー401 応答を受け取った後に認証のための情報を利用者に求めるダイアログボックスを表示し、 そこで入力された情報を用いて再度 Authorization: ヘッダー付きの要求を繰り返すことによって認証の通過を試みます。

[402] しかし最初から Authorization: ヘッダー付きで要求を送ることも認められています。 例えば Webブラウザーは以前利用者が入力した認証のための情報を記録しておき、 以後それを自動的に使うことがあります。また、Webブラウザー以外の利用者エージェントは、 実行時の引数などから予め認証のための情報を受けとっておき、要求送信時にいきなりそれを使うように実装されていることもあります。

[9] 要求認可された場合で realm が指定されていた場合には、同じ realm の他の要求に対しても同じ credentials が有効であると考えられます >>3

[12] このヘッダーは複数指定できます。

処理

[10] HTTP認証も参照してください。

[403] Authorization: 欄付きの要求に対し、起源鯖はそれを使って認証できない場合に 401 応答を返すべきです >>407, >>416

[404] RFC 1945Authorization: 欄付きの要求に対し、 起源鯖はそれを受け付ける意思が (今後も) ない場合、 403 応答を返すことができるとされていました >>405RFC 2068 にはこの用法は明記されていません。

[406] プロキシは、要求Authorization: ヘッダーを変更してはなりません >>3, >>405, >>408, >>417, >>24

[2] Authorization: ヘッダーの有無は応答キャッシュ蓄積できるかに影響します。

詳しくはキャッシュ可能性を参照。
[47] RFC 1945 では Authorization: 欄を含む応答キャッシュ可能では無いとされていました >>46, >>405
[412] RFC 2068RFC 2616 では、 Cache-Control: によってキャッシュ可能性起源鯖側で指定できるようになっています (>>411, >>415, >>418)。

Authorization: を使わない credentials の指定

[17] credentialsAuthorization: 以外によって指定することも禁止されてはいません >>16 が、 Authorization: は自動的に Cache-Control: private のような効果を持つ (キャッシュ可能性参照。) のに対し、それ以外の方法では自動的にはキャッシュが禁止されませんから、 要求または応答Cache-Control: ヘッダーで明示的にキャッシュを制御する必要が生じます。

OAuth 1.0

[1] OAuth 1.0 では credentials要求Authorization: ヘッダーに指定することもできますが、要求URLquery に指定したり、 application/x-www-form-urlencodedpayload body に含めたりすることもできます。

要求引数を参照。

WSSE

[11] WSSE では Authorization: ヘッダーは指定しないか形式的に指定するだけで、 実際の credentialsX-WSSE: ヘッダーに指定することとなっています。

関連

[25] 応答challenge を指定する WWW-Authenticate: ヘッダーと似ています。

歴史

誕生

RFC 第1世代

RFC 第2世代

RFC 第3世代

[45] RFC 1945 (HTTP/1.0) 10.2; RFC 2068・2616 (HTTP/1.1) 14.8 Authorization

A user agent that wishes to authenticate itself with a server-- usually, but not necessarily, after receiving a 401 response--{1945} may {2068} MAY do {2616} does so by including an Authorization request-header field with the request. The Authorization field value consists of credentials containing the authentication information of the user agent for the realm of the resource being requested.

サーバーに (普通は、でも必要ではないけど、 401 応答を受け取った後に)、 認証されたいと思う利用者代理者は、 Authorization 要求頭欄を要求に 含めることでそう出来ます。 Authorization 欄の値は 要求されている資源の領域に対しての利用者代理者の認証情報を含んだ 証明書で構成されます。

  • Authorization = "Authorization" ":" credentials

HTTP access authentication is described in {1945・2068} section 11 {2616} "HTTP Authentication: Basic and Digest Access Authentication" [43]. If a request is authenticated and a realm specified, the same credentials {1945} should {2068} SHOULD be valid for all other requests within this realm {2616} (assuming that the authentication scheme itself does not require otherwise, such as credentials that vary according to a challenge value or using synchronized clocks).

HTTP 接続認証は『HTTP 認証: 基本接続認証と要約接続認証』 で説明されています。要求が認証されて領域が指定されていれば、 同じ証明書が当該領域内のすべての他の要求に対して妥当である べきです。 (認証方式自体はそうでないことを必要としない (例えば挑戦値により変化する証明書や同期時計の使用が無い) と仮定します。)

{1945} Responses to requests containing an Authorization field are not cachable.

Authorization 欄を含んだ要求に対する応答はキャッシュ可能ではありません。

[411]

{2068〜} When a shared cache (see section 13.7) receives a request containing an Authorization field, it MUST NOT return the corresponding response as a reply to any other request, unless one of the following specific exceptions holds:

共有キャッシュが Authorization 欄を含んだ要求を受け取った時、 他のどの要求への返信としても対応する応答を返してはいけません。 但し次のうちのいずれかの例外を除きます。

  1. 1. If the response includes the {2068} "proxy-revalidate" Cache-Control {2616} "s-maxage" cache-control directive, the cache MAY use that response in replying to a subsequent request, but {2068} . But (if the specified maximum age has passed) {2616} a proxy cache MUST first revalidate it with the origin server, using the request-headers from the new request to allow the origin server to authenticate the new request. {2616} (This is the defined behavior for s-maxage.) If the response includes "s-maxage=0", the proxy MUST always revalidate it before re-using it.
  2. 2. If the response includes the "must-revalidate" Cache-Control cache-control directive, the cache MAY use that response in replying to a subsequent request, but. But if the response is stale, all caches MUST first revalidate it with the origin server, using the request-headers from the new request to allow the origin server to authenticate the new request.
  3. 3. If the response includes the "public" Cache-Control cache-control directive, it may MAY be returned in reply to any subsequent request.
  1. 応答が "s-maxage" cache-control 指令を含んでいたら、キャッシュは 後続要求に返信するのにその応答を使っても構いません。 しかし (指定された最大年令が経過したら) 串キャッシュはまず 源サーバーと再検証しなければなりません。 そのとき新しい要求からの要求頭を使って源サーバーが新しい要求を 認証出来るようにします。 (これは s-maxage に定義された振舞いです。) 応答が "s-maxage=0" を含んでいる場合、串は再利用する前に常に 再検証しなければなりません
  2. 応答が "must-revalidate" cache-control 指示を含んでいる場合、 キャッシュはその応答を後続要求への返信に使っても構いません。 しかし要求が腐ったら全てのキャッシュはまず源サーバーで 再検証しなければなりません。この時新しい要求からの 要求頭を使って源サーバーが新しい要求を認証出来るようにします。
  3. 要求が "public" cache-control 指示を含んでいる場合、 どの後続要求への返信でも返して構いません

[422] RFC 3507 - Internet Content Adaptation Protocol (ICAP) ( ( 版)) <http://tools.ietf.org/html/rfc3507#page-14>

RFC 第4世代

メモ

[419] IRC logs: freenode / #whatwg / 20130506 ( ( 版)) <http://krijnhoetmer.nl/irc-logs/whatwg/20130506>

[420] Re: Re: Re: Fetch: HTTP authentication and CORS ( (Hallvord Reiar Michaelsen Steen 著, 版)) <http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0522.html>

[421] GCM HTTP Connection Server | Android Developers ( ( 版)) <https://developer.android.com/google/gcm/http.html>

[19] HTTP Headers and Query String Parameters - Cloud Storage — Google Cloud Platform ( 版) <https://cloud.google.com/storage/docs/reference-headers#authorization>

Valid Values

An authentication identifier ( OAuth | GOOG1 | AWS ) followed by one of the following:

A valid OAuth 2.0 token

An access key

A signature

Example

Authorization: OAuth 1/zVNpoQNsOSxZKqOZgckhpQ

[20] ( 版) <http://storage.sakura.ad.jp/pdf/base_storage_api_reference.pdf>

さくらの BASE Storage では、バケットレベルでの認証をサポートします

認証情報は、リクエストヘッダ内の Authorization フィールドに記述します

Authorization: <ユーザ名>:<アクセストークン>

認証パラメータ

パラメータ名 説明

Expires 署名(Signature)の 期限を エポックタイム で指定します

サーバは この時間以降のリクエストは破棄します

ユーザ名 コントロールパネルに表示される ユーザ名を指定します

アクセストークン コントロールパネルに表示される トークンを指定します

[21] API Authentication | DataSift Developers ( 版) <http://dev.datasift.com/docs/api/rest-api/api-authentication>

You need to include a header that contains:

    Authorization: datasift-user:your-datasift-api-key

Authorization: <username>:<api_key>

[22] Push Notifications on the Open Web | Web Updates - Google Developers ( 版) <https://developers.google.com/web/updates/2015/03/push-notifications-on-the-open-web>

curl --header "Authorization: key=<YOUR_API_KEY>"

[23] Implementing an HTTP Connection Server  |  Cloud Messaging  |  Google Developers ( 版) <https://developers.google.com/cloud-messaging/http>

Authorization:key=AIzaSyZ-1u...0GBYzPu7Udno5aA

[26] Fix #198: give precedence to custom Authorization headers · whatwg/fetch@9b18866 ( 版) <https://github.com/whatwg/fetch/commit/9b188662ab3d0319fe6e5fc10f034a9f10f7b069>

[27] 複数の端末にメッセージを送信する  |  Firebase ( ()) <https://firebase.google.com/docs/cloud-messaging/js/send-multiple>

https://fcm.googleapis.com/fcm/send

Content-Type: application/json

Authorization: key=AIzaSyC...akjgSX0e4

[28] Firebase Cloud Messaging サーバーについて  |  Firebase ( ()) <https://firebase.google.com/docs/cloud-messaging/server>

Authorization: key=YOUR_SERVER_KEY

これがサーバーキーであることを確認してください。この値は、Firebase console の [設定] ペインの [クラウド メッセージング] タブで確認できます。Android、iOS、およびブラウザのキーは、FCM によって拒否されます。