[5] Authorization:
ヘッダーは、
HTTP認証のためのクライアントの credentials を指定するものです。
[6] Authorization:
ヘッダーは、
利用者エージェントが起源鯖において認証するためのもので、
要求されている資源の保護空間における利用者エージェントの認証情報を含む
credentials を指定するものです >>3。
[410] Authorization:
ヘッダーの値は credentials です
>>3, >>409, >>413。
[34]
なぜか Authorization
で独自の構文を採用するWebサービスが多々あります。
鍵
#✎[35] API guide — CKAN 2.10.4 documentation, , https://docs.ckan.org/en/2.10/api/index.html#authentication-and-api-tokens
名前:鍵
#✎さくらの BASE Storage では、バケットレベルでの認証をサポートします
認証情報は、リクエストヘッダ内の Authorization フィールドに記述します
Authorization: <ユーザ名>:<アクセストークン>
認証パラメータ
パラメータ名 説明
Expires 署名(Signature)の 期限を エポックタイム で指定します
サーバは この時間以降のリクエストは破棄します
ユーザ名 コントロールパネルに表示される ユーザ名を指定します
アクセストークン コントロールパネルに表示される トークンを指定します
You need to include a header that contains:
Authorization: datasift-user:your-datasift-api-key
Authorization: <username>:<api_key>
key=鍵
#✎[421] GCM HTTP Connection Server | Android Developers ( ( 版)) https://developer.android.com/google/gcm/http.html
curl --header "Authorization: key=<YOUR_API_KEY>"
Authorization:key=AIzaSyZ-1u...0GBYzPu7Udno5aA
https://fcm.googleapis.com/fcm/send
Content-Type: application/json
Authorization: key=AIzaSyC...akjgSX0e4
Authorization: key=YOUR_SERVER_KEY
これがサーバーキーであることを確認してください。この値は、Firebase console の [設定] ペインの [クラウド メッセージング] タブで確認できます。Android、iOS、およびブラウザのキーは、FCM によって拒否されます。
旧
Authorization: key=AIzaSyZ-1u...0GBYzPu7Udno5aA
新
Authorization: Bearer ya29.ElqKBGN2Ri_Uz...HnS_uNreA
[7] Authorization:
ヘッダーは通常
401
応答を受け取った後の要求で使いますが、
必ずしもそうでなくても構いません >>3。
[48] 通常 Webブラウザーは 401
応答を受け取った後に認証のための情報を利用者に求めるダイアログボックスを表示し、
そこで入力された情報を用いて再度 Authorization:
ヘッダー付きの要求を繰り返すことによって認証の通過を試みます。
[402] しかし最初から Authorization:
ヘッダー付きで要求を送ることも認められています。
例えば Webブラウザーは以前利用者が入力した認証のための情報を記録しておき、
以後それを自動的に使うことがあります。また、Webブラウザー以外の利用者エージェントは、
実行時の引数などから予め認証のための情報を受けとっておき、要求送信時にいきなりそれを使うように実装されていることもあります。
[403] Authorization:
欄付きの要求に対し、起源鯖はそれを使って認証できない場合に
401
応答を返すべきです
>>407, >>416。
Authorization:
欄付きの要求に対し、
起源鯖はそれを受け付ける意思が (今後も)
ない場合、 403
応答を返すことができるとされていました >>405。
RFC 2068 にはこの用法は明記されていません。[406] プロキシは、要求の Authorization:
ヘッダーを変更してはなりません >>3, >>405, >>408, >>417, >>24。
[2] Authorization:
ヘッダーの有無は応答をキャッシュに蓄積できるかに影響します。
Authorization:
を使わない credentials の指定#✎[17] credentials は Authorization:
以外によって指定することも禁止されてはいません
>>16 が、 Authorization:
は自動的に
Cache-Control: private
のような効果を持つ
(キャッシュ可能性参照。) のに対し、それ以外の方法では自動的にはキャッシュが禁止されませんから、
要求または応答の Cache-Control:
ヘッダーで明示的にキャッシュを制御する必要が生じます。
[11] WSSE では Authorization:
ヘッダーは指定しないか形式的に指定するだけで、
実際の credentials は X-WSSE:
ヘッダーに指定することとなっています。
[1] OAuth 1.0 では credentials を要求のAuthorization:
ヘッダーに指定することもできますが、
要求URLの query に指定したり、
application/x-www-form-urlencoded
な payload body
に含めたりもできます。
[29] OAuth 2.0 bearer は要求の
Authorization:
ヘッダーに指定することもできますが、
要求URLの query に指定したり、
application/x-www-form-urlencoded
な payload body
に含めたりもできます。
Bearer
[32] 各種 Webサービスの提供する Web API は、 自社サービス専用の独自の方法 (独自の HTTPヘッダー、 独自の query parameter など) を使った指定方法を定めていることが、 割とよくあります。
[33] 歴史的経緯 (21世紀初頭からサービスを続けているとか) を除けば、 そのような標準的でない方法を採用するメリットは皆無に等しいです。 新しいサービスがそのような手法を採っているとしたら、 HTTP に詳しくない人が設計した可能性を疑わざるを得ません。
[25] 応答で challenge を指定する
WWW-Authenticate:
ヘッダーと似ています。
A user agent that wishes to authenticate itself with a server-- usually, but not necessarily, after receiving a 401 response--
{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.{1945} may{2068} MAY do
サーバーに (普通は、でも必要ではないけど、 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
欄を含んだ要求に対する応答はキャッシュ可能ではありません。
{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
{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. If the response includes the "must-revalidate"
Cache-Controlcache-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. If the response includes the "public"
Cache-Controlcache-control directive, itmayMAY be returned in reply to any subsequent request.
[422] RFC 3507 - Internet Content Adaptation Protocol (ICAP) ( ( 版)) http://tools.ietf.org/html/rfc3507#page-14
[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
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
[26] Fix #198: give precedence to custom Authorization headers · whatwg/fetch@9b18866 ( 版) https://github.com/whatwg/fetch/commit/9b188662ab3d0319fe6e5fc10f034a9f10f7b069
[31] SafariはBasic認証の結果でAuthorization: Bearerを上書きする - Qiita () https://qiita.com/ksakiyama134/items/efad0e48464e0f501d76