token credentials request

アクセストークン (OAuth)

[69] アクセストークン (access token) は、 OAuth において資源鯖上の資源にアクセスするためのトークンです。

仕様書

アクセストークンの種類

[70] アクセストークンプロトコルによって何種類か違いがあります。

[72] 例えば OAuth2Bearer 認証方式では、 持参人トークン (ベアラートークン) と呼ばれる種類のものを使います。

OAuth 1.0 トークン credentials

[21] トークン (token) は、 が発行する固有の識別子であり、 認証された要求クライアント認可を要求している、または取得した資源所有者とを関連付けるためクライアントが使うものです >>1OAuth 1.0 で用いられる credentials の一種で、仕様書中ではしばしばトークンcredentials (token credentials) とも呼ばれています。

[22] トークンcredentialsは、 トークン識別子 (token identifier) トークン共有秘密 (token shared-secret) で構成されます。

[2] 元はそれぞれ access token および access token secret と呼んでいました >>1
[29] トークン識別子認証された要求に直接含めて送信されますが、 トークン共有秘密は直接は含まれません。トークン識別子は公開されても問題は無いはずですが、 通常その必要がないのでクライアントの間でだけ共有されます。 トークン共有秘密クライアントの間で秘密にする必要があります。
[31] 厳密性を必要としない場面では、アクセストークンアクセストークン秘密をまとめて「アクセストークン」と呼ぶこともあります。

[66] Evernote ではトークン共有秘密は常に空文字列です >>65

OAuth 2.0 アクセストークン

[24] アクセストークン (access token) は、 被保護資源へのアクセスに使うcredentials であり、 クライアントに発行された認可 (資源所有者承諾したアクセスの範囲 (scope) や期間) を表す文字列です >>23

[25] 通常この文字列クライアントには不透明なものです >>23アクセストークン認可情報を取得するために使う識別子でも構いませんし、 それ自体に認可情報 (と検証するための署名) を含んでいても構いません >>23

[30] OAuth 1.0 アクセストークン識別子共有秘密の2つの値の組でしたが、 OAuth 2.0 アクセストークンは1つの値です。

[20] アクセストークンを構成する文字は、access_token 引数の構文より、1つ以上の印字可能ASCII文字に制限されます。

アクセストークン型によっては更に制限があります。
[44] アクセストークン型によってはアクセストークン自体の他に、 いくつかの追加の引数を使うことがあります。アクセストークン型を参照。

[60] アクセストークンの長さは、 OAuth 仕様上制限がありません。 クライアントアクセストークンの長さに仮定を置くべきではありません。 認可鯖は、アクセストークンの長さを明文化するべきです>>58, >>71

[15] 認可鯖は、アクセストークンを推測できないようにしなければなりません >>6, >>17。 攻撃者が推測できる確率は 2-128 以下なければならず、 2-160 以下であるべきです >>17

[41] 攻撃者が認可鯖認可符号を発行させる操作を大量に実行して認可符号を枯渇させるようなDoS攻撃があり得ますから、 利用者ごとに発行数を制限するなど、対策を講じるべきです >>42

[26] クライアントアクセストークンを使う際に、その他の認証credentials が必要であっても構いません (が、 OAuth の仕様の範囲外です) >>23

[27] 例えば OAuth とは別に基本認証credentials が必要かもしれません。

[11] アクセストークンは、転送や蓄積において機密を保持しなければならず認可鯖、適用対象の資源鯖、発行先のクライアントのみの間で共有しなければなりません >>6

[14] 暗示的承諾型では資源所有者アクセストークンが転送されるため、 この要件を完全には満たせません。

[28] アクセストークンは、認可承諾フローにより、 あるいは更新トークンを使って取得できます。

[4] アクセストークンには、種別 (トークン型) があり、それによって被保護資源にアクセスする際の認証方式が異なります。

[12] アクセストークンは、HTTPS サーバー認証のもとでしか転送してはなりません >>6, >>16

[13] アクセストークン認可エンドポイントトークンエンドポイントで用いられますが、そこでは TLS が要求されています。 リダイレクトURLでは TLS が原則とされていますが、平文も限定的に認められており、 その場合は >>12 を満たせません。

アクセストークンの要求

[8] OAuth 1.0 では、クライアントトークン要求を送信することで、 トークンcredentials (アクセストークンアクセストークン秘密) を取得できます。

[9] OAuth 2.0 では、クライアントトークンエンドポイントに要求を送信することで、 アクセストークンを取得できます。 (暗示的承諾では、認可エンドポイントから取得できます。)

[45] Twitter は通常の OAuth フローとは別に、設定ページから access token, access token secret の組を発行する方法を用意しています >>46, >>47

[49] SlackAPI の説明ページでアクセストークンを提供しています >>48

[54] GitHubQiita >>53 などでは設定ページからアクセストークンを発行できます。

[68] 認可フローを実装せずに設定ページからしか取得できないらしきものもあります >>67

[58] Flickr は古い独自認証 API を使って OAuth 1.0 access token/access token secret を取得する API >>56 を用意しています。

[64] DropboxOAuth 1.0 を使って OAuth 2.0 アクセストークンを取得する API >>63 を用意しています。

[51] GitHub などはアクセストークンを発行する API も提供しています >>50, >>52, >>61, >>62GitHub の場合は基本認証を使ったりします。 Bitly の場合はトークンエンドポイントを共有しており、 「OAuth Basic Authentication Flow」などとも称しているものの OAuth とは異なる方法で基本認証を使ったアクセストークン取得 API を提供しています >>55Heroku は独自のAPIトークン基本認証合言葉として使って (利用者名空文字列。) アクセストークンを取得する API を提供しており、 OAuth で発行されたものと違って無期限になります >>61

アクセストークンの利用

[10] アクセストークンを利用した被保護資源へのアクセス方法については、 資源鯖を参照。

OAuth 1.0 トークンcredentialsの破棄

[5] は、 token credentialsクライアントに後に、 資源所有者token credentials を取り消し (revoke) できるようにするべきです >>3

response_type=token

[32] OAuth 2.0 認可エンドポイントresponse_type 引数の値 token は、アクセストークンを要求している (暗示的承諾型である) ことを意味します >>33, >>57

access_token 引数

[59] OAuth 2.0 認可エンドポイントからのリダイレクトURLに追加される素片識別子引数 access_token は、アクセストークンを表します。 この引数必須です >>58

[81] OAuth 2.0 トークンエンドポイントからの JSON 応答引数 access_token は、アクセストークンを表します。 この引数必須です >>71

[19] この引数の値は、1文字以上の印字可能ASCII文字の列です >>18

[35] 資源鯖access_token 引数 >>34 は、 認証に使うアクセストークンを表します。

token_type_hint=access_token

[37] token_type_hint 引数の値 access_token は、アクセストークンを表します >>36

セキュリティー

[39] クライアントは、アクセストークンを保存したストレージ等に攻撃者がアクセスできないか注意する必要があります >>38。 同じ環境で動作する他のプログラムからストレージにアクセスできるかもしれません。 動作している端末全体が盗まれることもあるかもしれません >>38, >>43

[40] そのような場合の対策という意味でも、認可鯖資源所有者に対して発行済のアクセストークンrevoke させられる仕組みを提供するべきでしょう。