[26] 更新トークンは、 アクセストークンを取得するために使うことができるトークン (credentials) です。 認可鯖がアクセストークンの寿命を短めに設定している場合に、 クライアントが認可鯖から新しいアクセストークンを取得するために使うことができます。
[2] 更新トークンは、 アクセストークンを得るために使う credentials です >>1。 更新トークンは、資源所有者のクライアントへの認可承諾を表す文字列です >>1。
[4] クライアントは現在のアクセストークンが非妥当や満期になって新しいアクセストークンを得たい時や、 同じかより狭い適用範囲 (scope) のアクセストークンを追加で取得したい時に使います >>1。
[3] 更新トークンは、認可鯖がクライアントに発行します >>1。 認可鯖はWebアプリケーションやネイティブアプリケーションのクライアントに更新トークンを発行して構いません >>20。
[25] 認可鯖は、更新トークンを推測できないようにしなければなりません >>20, >>28。 攻撃者が推測できる確率は 2-128 以下でなければならず、 2-160 以下であるべきです >>28。
[16] 認可鯖は、各更新トークンについて次の情報を保持しています。
[21] 更新トークンは転送や蓄積に当たり機密性を保持しなければならず、 認可鯖と発行先のクライアントの間でのみ共有しなければなりません >>20。
[22] 更新トークンは HTTPS サーバー認証のもとでのみ転送しなければなりません >>20, >>27。
[23] 認可鯖はクライアントの identity を認証できるなら、 更新トークンとクライアントの対応が正しいか検証しなければなりません。 クライアント認証が不可能な時は、その他の方法で乱用を防止するべきです。 >>20
[31] refresh_token 引数の構文上の制約により、
1つ以上の印字可能ASCII文字で構成される必要があります。
[12] 更新トークンの長さは、 OAuth 仕様としては制限を設けていません。 鯖は、発行する更新トークンの長さを明文化するべきです。 >>11
[6] 更新トークンを発行するかどうかは、認可鯖が決めることができます >>1。 発行する場合には、トークンエンドポイントによるアクセストークンの発行時に更新トークンを含めます >>1, >>11。
[10] 暗示的承諾型フローでの認可エンドポイントでのアクセスでは認可鯖は更新トークンを発行してはなりません >>9。
[18] 更新トークンは、トークンエンドポイントでアクセストークンを取得するために使うことができます。
refresh_token 引数[13] トークンエンドポイントのアクセストークンを含む JSON 応答の
refresh_token 引数 >>11 には、
認可鯖が発行した更新トークンを指定してクライアントに通知できます。
[19] トークンエンドポイントで更新トークンからアクセストークンを得る要求における
refresh_token 引数 >>14 は、
クライアントが保持している更新トークンを指定するものです。
[30] 値は、1文字以上の印字可能ASCII文字の列です >>29。
grant_type=refresh_token[15] トークンエンドポイントの grant_type 引数の値
refresh_token >>14 は、
更新トークンからアクセストークンを取得しようと試みていることを表します。
token_type_hint=access_token[32] token_type_hint 引数の値
access_token は、アクセストークンを表します >>33。
[35] 更新トークンをストレージ等に保存する際は、攻撃者がアクセス可能にならないか注意する必要があります >>34。システムによっては同じ環境で動作する他のアプリケーションからファイルシステム等に保存された更新トークンにアクセス可能かもしれません。また更新トークンが保存された携帯電話等の装置自体が盗まれる可能性もあります >>34。 (ですから、認可鯖はクライアントに発行した更新トークンを後から revoke する方法を資源所有者に提供するべきです。)
[36] scooe=offline_access も参照。