3. Implementation Note (実装上の注意)

3. Implementation Note (実装上の注意)

OAuth 2.0 では、アクセストークンのスタイルに関して柔軟なデプロイメントが可能です。アクセストークンは自己完結型にすることができるため、resource server (リソースサーバー) は、保護されたリソースへのアクセスを要求するクライアントの認可決定を実行するために、これらのトークンを発行する認可サーバーとそれ以上やり取りする必要はありません。ただし、システム設計によっては、代わりに認可サーバーに保存されている認可データを参照するハンドルであるアクセストークンを使用する場合があります。その結果、これには、クライアントがアクセストークンを提示するたびに、リソースサーバーが対応する認可サーバーにリクエストを発行してアクセストークンのコンテンツを取得する必要があります。

これらが唯一のオプションではありませんが、無効化への影響を示しています。後者の場合、認可サーバーは、リソースサーバーが受信したアクセストークンを中継するときに、以前にクライアントに発行されたアクセストークンを無効にすることができます。前者の場合、アクセストークンの即時無効化が望ましい場合、認可サーバーとリソースサーバーの間で何らかの（現在は標準化されていない）バックエンドのやり取りが使用される場合があります。別の設計上の代替案は、対応するリフレッシュトークンを使用していつでもリフレッシュできる短命のアクセストークンを発行することです。これにより、認可サーバーは、アクセストークンが使用されているときに無効化される時間の制限を課すことができます。

どのトークン無効化アプローチを選択するかは、システム全体の設計とアプリケーションサービスプロバイダーのリスク分析に依存します。必要な状態と通信オーバーヘッドの観点からの無効化のコストは、最終的には望ましいセキュリティプロパティの結果です。