要約

  • GNAP の continuation access token はクライアントの鍵に束縛され、一つのグラント要求を続けるためのもので、保護されたリソースに使うものではない。
  • 要求が pending の間は API 用トークンも subject 情報も渡せない。利用者とのやり取りが終わっても、認可サーバーは要求全体を改めて評価する。

利用者が確認画面を終えた、という表示はしばしば最終結果のように見える。しかしそれは、ブラウザがクライアントへ戻ったこと、クライアントが継続 URI を得たこと、または鍵の保有を署名で示したことを意味するにすぎない。それだけでは、このクライアントが今この API にこの操作を要求できるかは分からない。

RFC 9635 の GNAP は、その飛躍を避ける状態機械である。クライアントは認可サーバーにグラント要求を送る。同意や利用者との対話がなお必要なら、要求は pending になる。この状態でサーバーは継続情報を返せるが、API access token を発行したり subject 情報を返したりしてはならない。アクセスを巡る会話は続いているが、アクセス自体はまだ得られていない。

継続資格情報の役割は意図的に狭い。クライアントの鍵に束縛され、bearer token ではなく、継続 URI に対して鍵の証明とともに提示される。認可サーバーは署名と期待する鍵との対応を検証する。これは誰が同じ会話を続けられるかを守る仕組みであり、リソースサーバーでの実行許可ではない。

RFC はこの隔たりを両方向に明記する。通常の access token は継続エンドポイントでは使えず、反対に継続 access token は、認可サーバーと同居していても、リソースサーバーへの認可済み要求には使えない。文字列が似ていても、検証者、URI、状態、許される効果は同じにならない。

対話の終了も判定を自動化しない。対話後、認可サーバーは要求を processing に戻し、資源所有者が承認した場合も拒否した場合も、全体の文脈を再評価する。承認済みの要求だけが API token や subject 情報を返せる。finalized になった要求は新しい token を発行できず、情報も対話も再開できない。将来のアクセスには新しい要求が必要である。

トークン管理はさらに別の面である。API token には、回転や失効に使う別個の管理 URI と管理資格情報が付くことがある。回転は元の token の権利と属性を保つのであり、権利を広げない。別の権利が必要なら、継続による更新と再評価、または新規要求がいる。管理の連続性は権限の拡張ではない。

リソースサーバーにも固有の検証面が残る。GNAP の API token は定められた鍵の証明とともに提示され、リソースサーバーは token がない、または無効な要求に challenge を返せる。それでも、業務目的が今も妥当か、実行条件が満たされるか、操作の効果が起きたかまでは証明しない。

保存すべき証拠は別々である。要求 ID と求めた access、pending 状態、継続 URI と鍵の証明、対話結果、認可サーバーの再評価、発行済み API token の範囲、リソースサーバーの検証、要求受領、観測された効果。これらを一語の「認可済み」に圧縮すれば、プロトコルが残した責任境界を消してしまう。

出典