[69] アクセストークンは、 OAuth において資源鯖上の資源にアクセスするためのトークンです。
[70] アクセストークンはプロトコルによって何種類か違いがあります。
[72]
例えば OAuth2 の Bearer 認証方式では、
持参人トークン
(ベアラートークン)
と呼ばれる種類のものを使います。
[21] トークンは、 鯖が発行する固有の識別子であり、 認証された要求とクライアントが認可を要求している、または取得した資源所有者とを関連付けるためクライアントが使うものです >>1。 OAuth 1.0 で用いられる credentials の一種で、仕様書中ではしばしばトークンcredentialsとも呼ばれています。
[22] トークンcredentialsは、 トークン識別子とトークン共有秘密で構成されます。
[24] アクセストークンは、 被保護資源へのアクセスに使うcredentials であり、 クライアントに発行された認可 (資源所有者が承諾したアクセスの範囲 (scope) や期間) を表す文字列です >>23。
[25] 通常この文字列はクライアントには不透明なものです >>23。 アクセストークンは認可情報を取得するために使う識別子でも構いませんし、 それ自体に認可情報 (と検証するための署名) を含んでいても構いません >>23。
[20] アクセストークンを構成する文字は、access_token
引数の構文より、1つ以上の印字可能ASCII文字に制限されます。
[60] アクセストークンの長さは、 OAuth 仕様上制限がありません。 クライアントはアクセストークンの長さに仮定を置くべきではありません。 認可鯖は、アクセストークンの長さを明文化するべきです。 >>58, >>71
[15] 認可鯖は、アクセストークンを推測できないようにしなければなりません >>6, >>17。 攻撃者が推測できる確率は 2-128 以下でなければならず、 2-160 以下であるべきです >>17。
[41] 攻撃者が認可鯖に認可符号を発行させる操作を大量に実行して認可符号を枯渇させるようなDoS攻撃があり得ますから、 利用者ごとに発行数を制限するなど、対策を講じるべきです >>42。
[26] クライアントがアクセストークンを使う際に、その他の認証の credentials が必要であっても構いません (が、 OAuth の仕様の範囲外です) >>23。
[11] アクセストークンは、転送や蓄積において機密を保持しなければならず、 認可鯖、適用対象の資源鯖、発行先のクライアントのみの間で共有しなければなりません >>6。
[28] アクセストークンは、認可承諾フローにより、 あるいは更新トークンを使って取得できます。
[4] アクセストークンには、種別 (トークン型) があり、それによって被保護資源にアクセスする際の認証方式が異なります。
[8] OAuth 1.0 では、クライアントは鯖にトークン要求を送信することで、 トークンcredentials (アクセストークンとアクセストークン秘密) を取得できます。
[9] OAuth 2.0 では、クライアントは鯖のトークンエンドポイントに要求を送信することで、 アクセストークンを取得できます。 (暗示的承諾では、認可エンドポイントから取得できます。)
[45] Twitter は通常の OAuth フローとは別に、設定ページから access token, access token secret の組を発行する方法を用意しています >>46, >>47。
[49] Slack は API の説明ページでアクセストークンを提供しています >>48。
[54] GitHub や Qiita >>53 などでは設定ページからアクセストークンを発行できます。
[68] 認可フローを実装せずに設定ページからしか取得できないらしきものもあります >>67。
[58] Flickr は古い独自認証 API を使って OAuth 1.0 access token/access token secret を取得する API >>56 を用意しています。
[64] Dropbox は OAuth 1.0 を使って OAuth 2.0 アクセストークンを取得する API >>63 を用意しています。
[51] GitHub などはアクセストークンを発行する API も提供しています >>50, >>52, >>61, >>62。 GitHub の場合は基本認証を使ったりします。 Bitly の場合はトークンエンドポイントを共有しており、 「OAuth Basic Authentication Flow」などとも称しているものの OAuth とは異なる方法で基本認証を使ったアクセストークン取得 API を提供しています >>55。 Heroku は独自のAPIトークンを基本認証の合言葉として使って (利用者名は空文字列。) アクセストークンを取得する API を提供しており、 OAuth で発行されたものと違って無期限になります >>61。
[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。
token_type_hint=access_token[37] token_type_hint 引数の値
access_token は、アクセストークンを表します >>36。
[39] クライアントは、アクセストークンを保存したストレージ等に攻撃者がアクセスできないか注意する必要があります >>38。 同じ環境で動作する他のプログラムからストレージにアクセスできるかもしれません。 動作している端末全体が盗まれることもあるかもしれません >>38, >>43。
[40] そのような場合の対策という意味でも、認可鯖は資源所有者に対して発行済のアクセストークンを revoke させられる仕組みを提供するべきでしょう。