151.txt

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

* 仕様書

[REFS[
- [3] '''[CITE@en[RFC 7235 - Hypertext Transfer Protocol (HTTP/1.1): Authentication]] ([TIME[2014-09-11 10:01:28 +09:00]] 版) <https://tools.ietf.org/html/rfc7235#section-4.2>'''
- [16] [CITE@en[RFC 7235 - Hypertext Transfer Protocol (HTTP/1.1): Authentication]] ([TIME[2014-09-11 10:01:28 +09:00]] 版) <https://tools.ietf.org/html/rfc7235#section-5.1.2>
- [15] [CITE@en[RFC 2326 - Real Time Streaming Protocol (RTSP)]] ([TIME[2014-10-19 05:24:58 +09:00]] 版) <http://tools.ietf.org/html/rfc2326#section-12.5>
- [14] [CITE@en[RFC 3261 - SIP: Session Initiation Protocol]] ([TIME[2014-08-15 14:48:03 +09:00]] 版) <http://tools.ietf.org/html/rfc3261#section-20.7>
- [13] [CITE@en[RFC 3261 - SIP: Session Initiation Protocol]] ([TIME[2014-08-15 14:48:03 +09:00]] 版) <http://tools.ietf.org/html/rfc3261#section-22.2>
- [18] [CITE@en[RFC 4976 - Relay Extensions for the Message Sessions Relay Protocol (MSRP)]] ([TIME[2014-10-18 23:44:47 +09:00]] 版) <https://tools.ietf.org/html/rfc4976#section-4.4>
- [24] [CITE@en[RFC 7616 - HTTP Digest Access Authentication]] ([TIME[2015-11-10 07:05:08 +09:00]] 版) <https://tools.ietf.org/html/rfc7616#section-3.6>
]REFS]

* 意味

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

* 構文

[410] [CODE(HTTP)@en[[[Authorization:]]]] [[ヘッダー]]の値は [[credentials]] です
[SRC[>>3, >>409, >>413]]。

[FIG(railroad)[
= [[credentials]]
]FIG]

;; [8] 複数の [[credentials]] を同時に指定する方法はありません。

;; [[credentials]]、[[auth-param]] も参照。

* 文脈

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

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

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

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

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

* 処理

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

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

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

[406] [[プロキシ]]は、[[要求]]の [CODE(HTTP)@en[[[Authorization:]]]] 
[[ヘッダー]]を変更しては[['''なりません''']] [SRC[>>3, >>405, >>408, >>417, >>24]]。

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

;; 詳しくは[[キャッシュ可能性]]を参照。

;; [47] [[RFC 1945]] では [CODE(HTTP)@en[[[Authorization:]]]] 欄を含む[[応答]]は[[キャッシュ可能]]では''無い''とされていました
[SRC[>>46, >>405]]。

;; [412] [[RFC 2068]] と [[RFC 2616]] では、 [CODE(HTTP)@en[[[Cache-Control:]]]] によって[[キャッシュ可能性]]を[[起源鯖]]側で指定できるようになっています
(>>411, >>415, >>418)。

* [CODE(HTTP)@en[Authorization:]] を使わない credentials の指定

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

** WSSE

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

** OAuth 1.0

[1] [[OAuth 1.0]] では [[credentials]] を[[要求]]の[CODE[Authorization:]] [[ヘッダー][HTTPヘッダー]]に指定することもできますが、
[[要求URL]]の [[query][URL query]] に指定したり、
[CODE[application/x-www-form-urlencoded]] な [[payload body]]
に含めたりもできます。
[SEE[ [[要求引数]] ]]

** OAuth 2.0

[29] [[OAuth 2.0]] [[bearer]] は[[要求]]の
[CODE[Authorization:]] [[ヘッダー][HTTPヘッダー]]に指定することもできますが、
[[要求URL]]の [[query][URL query]] に指定したり、
[CODE[application/x-www-form-urlencoded]] な [[payload body]]
に含めたりもできます。
[SEE[ [CODE[Bearer]] ]]

* 関連

[25] [[応答]]で [[challenge]] を指定する
[CODE(HTTP)@en[[[WWW-Authenticate:]]]]
[[ヘッダー]]と似ています。

* 歴史

** 誕生

[REFS[
- [44] [CITE[Request Headers in the HTTP protocol]]
( ([TIME[2001-11-29 11:01:38 +09:00]] 版))
<http://www.w3.org/Protocols/HTTP/HTRQ_Headers.html#z9>
]REFS]

** RFC 第1世代

[REFS[
- [46] [CITE@en[RFC 1945 - Hypertext Transfer Protocol -- HTTP/1.0]] ([TIME[2012-02-18 23:25:56 +09:00]] 版) <http://tools.ietf.org/html/rfc1945#section-10.2>
- [405] [CITE@en[RFC 1945 - Hypertext Transfer Protocol -- HTTP/1.0]] ([TIME[2012-02-18 23:25:56 +09:00]] 版) <http://tools.ietf.org/html/rfc1945#page-48>
]REFS]

** RFC 第2世代

[REFS[
- [407] [CITE@en[RFC 2068 - Hypertext Transfer Protocol -- HTTP/1.1]] ([TIME[2012-02-18 23:30:14 +09:00]] 版) <http://tools.ietf.org/html/rfc2068#section-11>
- [408] [CITE@en[RFC 2068 - Hypertext Transfer Protocol -- HTTP/1.1]] ([TIME[2012-02-18 23:30:14 +09:00]] 版) <http://tools.ietf.org/html/rfc2068#page-66>
- [409] '''[CITE@en[RFC 2068 - Hypertext Transfer Protocol -- HTTP/1.1]] ([TIME[2012-02-18 23:30:14 +09:00]] 版) <http://tools.ietf.org/html/rfc2068#section-14.8>'''
- [415] [CITE@en[RFC 2069 - An Extension to HTTP : Digest Access Authentication]] ([TIME[2012-02-26 10:05:21 +09:00]] 版) <http://tools.ietf.org/html/rfc2069#page-9>
]REFS]

** RFC 第3世代

[REFS[
- [418] [CITE@en[RFC 2617 - HTTP Authentication: Basic and Digest Access Authentication]] ([TIME[2012-01-09 21:04:30 +09:00]] 版) <http://tools.ietf.org/html/rfc2617#section-3.2.2.5>
- [413] '''[CITE@en[RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1]] ([TIME[2012-01-09 20:55:20 +09:00]] 版) <http://tools.ietf.org/html/rfc2616#section-14.8>'''
- [416] [CITE@en[RFC 2617 - HTTP Authentication: Basic and Digest Access Authentication]] ([TIME[2012-01-09 21:04:30 +09:00]] 版) <http://tools.ietf.org/html/rfc2617#page-4>
- [417] [CITE@en[RFC 2617 - HTTP Authentication: Basic and Digest Access Authentication]] ([TIME[2012-01-09 21:04:30 +09:00]] 版) <http://tools.ietf.org/html/rfc2617#page-5>
]REFS]

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

> A user agent that wishes to authenticate itself with a server--
usually, but not necessarily, after receiving a 401 response--[DEL[[DEL[[INS[{1945}]] may]] [INS[[INS[{2068}]] MAY]] do]] [INS[[INS[{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 [DEL[[INS[{1945・2068}]] section 11]] [INS[[INS[{2616}]] "HTTP Authentication: Basic and Digest Access Authentication" [43]]]. If a request
is authenticated and a realm specified, the same credentials [DEL[[INS[{1945}]] should]] [INS[[INS[{2068}]] SHOULD]]
be valid for all other requests within this realm [INS[[INS[{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 認証: 基本接続認証と要約接続認証』
で説明されています。要求が認証されて領域が指定されていれば、
同じ証明書が当該領域内のすべての他の要求に対して妥当である
'''べきです'''。 (認証方式自体はそうでないことを必要としない
(例えば挑戦値により変化する証明書や同期時計の使用が無い)
と仮定します。)

[DEL[

> [INS[{1945}]] Responses to requests containing an Authorization field are not
cachable.

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

[INS[
[411] 

> [INS[{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. If the response includes the [DEL[[INS[{2068}]] "proxy-revalidate" Cache-Control]] [INS[[INS[{2616}]] "s-maxage" cache-control]]
directive, the cache MAY use that response in replying to a
subsequent request[DEL[, but [INS[{2068}]] ]][INS[. But (if the specified maximum age has passed) [INS[{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. [INS[[INS[{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. If the response includes the "must-revalidate" [DEL[Cache-Control]] [INS[cache-control]]
directive, the cache MAY use that response in replying to a
subsequent request[DEL[, but]][INS[. 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. If the response includes the "public" [DEL[Cache-Control]] [INS[cache-control]] directive, it [DEL[may]] [INS[MAY]] be returned in reply to any subsequent request.

= 応答が "s-maxage" cache-control 指令を含んでいたら、キャッシュは
後続要求に返信するのにその応答を使っても'''構いません'''。
しかし (指定された最大年令が経過したら) 串キャッシュはまず
源サーバーと再検証し'''なければなりません'''。
そのとき新しい要求からの要求頭を使って源サーバーが新しい要求を
認証出来るようにします。 (これは s-maxage に定義された振舞いです。)
応答が "s-maxage=0" を含んでいる場合、串は再利用する前に常に
再検証し'''なければなりません'''。
= 応答が "must-revalidate" cache-control 指示を含んでいる場合、
キャッシュはその応答を後続要求への返信に使っても'''構いません'''。
しかし要求が腐ったら全てのキャッシュはまず源サーバーで
再検証し'''なければなりません'''。この時新しい要求からの
要求頭を使って源サーバーが新しい要求を認証出来るようにします。
= 要求が "public" cache-control 指示を含んでいる場合、
どの後続要求への返信でも返して'''構いません'''。
]INS]
]FIG]

[422] [CITE@en[RFC 3507 - Internet Content Adaptation Protocol (ICAP)]]
( ([TIME[2014-06-08 07:17:07 +09:00]] 版))
<http://tools.ietf.org/html/rfc3507#page-14>

** RFC 第4世代

[REFS[
- [4] '''[CITE@en[RFC 7235 - Hypertext Transfer Protocol (HTTP/1.1): Authentication]] ([TIME[2014-09-11 10:01:28 +09:00]] 版) <https://tools.ietf.org/html/rfc7235#section-4.2>'''
]REFS]

* メモ

[419] [CITE[IRC logs: freenode / #whatwg / 20130506]]
( ([TIME[2013-05-16 21:16:27 +09:00]] 版))
<http://krijnhoetmer.nl/irc-logs/whatwg/20130506>

[420] [CITE@en[Re: Re: Re: Fetch: HTTP authentication and CORS]]
( ([[Hallvord Reiar Michaelsen Steen]] 著, [TIME[2013-05-07 05:39:35 +09:00]] 版))
<http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0522.html>

[421] [CITE[GCM HTTP Connection Server | Android Developers]]
( ([TIME[2014-09-01 09:58:32 +09:00]] 版))
<https://developer.android.com/google/gcm/http.html>

[FIG(quote)[
[FIGCAPTION[
[19] [CITE@en[HTTP Headers and Query String Parameters - Cloud Storage — Google Cloud Platform]]
([TIME[2015-05-27 08:55:19 +09:00]] 版)
<https://cloud.google.com/storage/docs/reference-headers#authorization>
]FIGCAPTION]

> 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

]FIG]


[FIG(quote)[
[FIGCAPTION[
[20] ([TIME[2014-07-03 18:27:57 +09:00]] 版)
<http://storage.sakura.ad.jp/pdf/base_storage_api_reference.pdf>
]FIGCAPTION]

> さくらの BASE Storage では、バケットレベルでの認証をサポートします
> 認証情報は、リクエストヘッダ内の Authorization フィールドに記述します
> Authorization: <ユーザ名>:<アクセストークン>
> 認証パラメータ
> パラメータ名 説明
> Expires 署名(Signature)の 期限を エポックタイム で指定します
> サーバは この時間以降のリクエストは破棄します
> ユーザ名 コントロールパネルに表示される ユーザ名を指定します
> アクセストークン コントロールパネルに表示される トークンを指定します

]FIG]


[FIG(quote)[
[FIGCAPTION[
[21] [CITE[API Authentication | DataSift Developers]]
([TIME[2015-08-28 22:01:15 +09:00]] 版)
<http://dev.datasift.com/docs/api/rest-api/api-authentication>
]FIGCAPTION]

> You need to include a header that contains:
>     Authorization: datasift-user:your-datasift-api-key
> Authorization: <username>:<api_key>

]FIG]


[FIG(quote)[
[FIGCAPTION[
[22] [CITE[Push Notifications on the Open Web | Web Updates - Google Developers]]
([TIME[2015-11-20 02:42:52 +09:00]] 版)
<https://developers.google.com/web/updates/2015/03/push-notifications-on-the-open-web>
]FIGCAPTION]

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

]FIG]


[FIG(quote)[
[FIGCAPTION[
[23] [CITE@en[Implementing an HTTP Connection Server  |  Cloud Messaging  |  Google Developers]]
([TIME[2015-10-21 05:19:34 +09:00]] 版)
<https://developers.google.com/cloud-messaging/http>
]FIGCAPTION]

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

]FIG]

[26] [CITE@en[Fix #198: give precedence to custom Authorization headers · whatwg/fetch@9b18866]]
([TIME[2016-01-22 23:28:02 +09:00]] 版)
<https://github.com/whatwg/fetch/commit/9b188662ab3d0319fe6e5fc10f034a9f10f7b069>

[FIG(quote)[
[FIGCAPTION[
[27] [CITE@ja[複数の端末にメッセージを送信する  |  Firebase]]
( ([TIME[2017-02-24 05:39:23 +09:00]]))
<https://firebase.google.com/docs/cloud-messaging/js/send-multiple>
]FIGCAPTION]

> https://fcm.googleapis.com/fcm/send
> Content-Type: application/json
> Authorization: key=AIzaSyC...akjgSX0e4

]FIG]


[FIG(quote)[
[FIGCAPTION[
[28] [CITE@ja[Firebase Cloud Messaging サーバーについて  |  Firebase]]
( ([TIME[2017-02-24 05:39:30 +09:00]]))
<https://firebase.google.com/docs/cloud-messaging/server>
]FIGCAPTION]

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

]FIG]