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

仕様書

アクセストークンの種類

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

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

OAuth 1.0 トークン credentials

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

アクセストークンの利用

[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 させられる仕組みを提供するべきでしょう。