要約

  • 個々の操作に必要な認証条件は、API への要求が届いてから決まることがある。条件を追加できる仕組みには意味があるが、その実現可能性までは保証されない。
  • 新しいアクセストークンを受け取っても、必要な認証イベントが新たに起きたとは限らない。同じ不足を残した再試行は、利用者の負担だけを増やし得る。
  • 再認証を促す権限には、実行可能な手段、打ち切り条件、適切な情報開示、端末や復旧支援の費用分担を伴わせる必要がある。

仕様の外に残る利用者

ある操作を行うには、追加の端末が必要だとする。その端末を手元に持っている担当者による実演は成功する。API は適切に拒否し、認証画面が開き、必要な操作を終えるとアクセスできる。製品の機能確認としては有用である。

だが、その実演だけでは、出張先にいる利用者や、登録を終えていない利用者の作業まで成立するとは分からない。これは特定の導入事例ではなく、計画を点検するための仮定である。確認したいのは、機能の有無ではなく、要求を満たす手段が対象者に届いているかどうかだ。

リソースを守るチームが条件を強めると、そのための仕事は別の場所へ移ることがある。本人確認基盤の担当者、アプリケーションの担当者、問い合わせ窓口、そして利用者である。条件を決めた側の変更量が小さくても、全体の負担が小さいとは限らない。

もちろん、API 側に条件を見直す余地は必要だ。個別の操作が持つリスクは、最初のトークン発行時には分からないこともある。すべてを早い段階の判断に押し込めれば、必要な情報を使えなくなる。問題は追加要求そのものではなく、それを実現する責任が要求とは別の場所に置き去りになることである。

相互運用できる要求が、実行可能とは限らない

2023 年 9 月発行の RFC 9470 は、利用者の認証が不十分な場合、リソースサーバーが必要な認証コンテキストや新しさを示す仕組みを定義している。クライアントはその要求を認可サーバーへ渡し、結果を伴ってリソースへ戻る。

同じ文書は、サービス間のポリシーの組み合わせによって、利用者が満たせない条件が生じ得るとも説明する。利用者との対話を誘発できる仕組みの悪用にも注意を促している。標準化の成果と、標準が引き受けていない責任を一緒に読む必要がある。

調達条件に「追加認証に対応」とだけ書くと、この違いが抜け落ちる。対応するメッセージを送れることは製品の性質である。予定した利用者が予定した環境で作業を終えられることは、サービス全体の性質だ。後者には対象者、登録状況、利用可能な手段、失敗した場合の扱いが含まれる。

困難な利用者がいるからといって、必要な条件を自動的に緩めるべきだという話ではない。できないことを何度も要求する代わりに、何が不足し、誰がその不足を解消できるかを決めておくという話である。

「強い認証」という一枚の札では足りない

ステップアップという言葉は、上に行くほど何にでも使える階段を連想させる。実際のポリシーはそれほど単純ではない。ある操作に必要なコンテキストが、別の操作にも適切とは限らない。認証方法の名前を並べるだけで、共通の強さの順位が決まるわけでもない。

OpenID Connect Core は、任意の希望として求める認証コンテキストと、対応する仕組みを使って必須と指定する値を区別する。また、認証からの経過時間の条件と、利用者にどのような対話を求めるかも区別している。

この違いは、運用契約の内容に直結する。リソース側は前提条件を伝えたつもりでも、認証側が希望として処理していれば、応答が正常でも必要な結果は得られない場合がある。

経営側がすべてのパラメーターを暗記する必要はない。しかし、要求した結果と実際に達成した結果が、同じ言葉で混同されていないかは確認すべきだ。「認証成功」という表示だけでは、その操作に必要な条件を満たしたかどうかは分からない。

終わらせるべき試行を、誰が終わらせるのか

利用者に提供できない認証コンテキストを要求した場面を考える。クライアントが新たな認可要求を送り、従来のコンテキストに基づく結果が返り、API がもう一度拒否する。途中の処理は動いていても、最初の不足が何も変わっていなければ、次の周回にも根拠は乏しい。

OpenID の認証要件未達を扱う仕様 は、指定された必須コンテキストを満たせない場合などに使う失敗信号を定義している。RFC 9470 も、アクセストークンの要求では求められたコンテキストを必要条件として扱うことを推奨し、不十分なトークンを返し続ける循環を避けようとしている。

それでも、画面の次の動作は別途決めなければならない。再試行を止めるのか、承認済みの代替手段を提示するのか、登録や復旧の担当者へ引き継ぐのか。失敗を示す機械向けの語があるだけでは、人に分かる出口はできない。

停止は、アクセスを認めることではない。必要条件を保ったまま、現状では完了できないと明示する選択肢もある。ここを曖昧にすると、使いやすさの名目で条件を外すか、条件を守る名目で同じ要求を無限に繰り返すかという、誤った二択になる。

再試行には状況の変化を求めるべきだろう。必要な端末が使えるようになった、登録が完了した、適切な認証イベントが起きた、といった変化である。これは本稿の運用上の提案であり、規格が一律の試行回数を定めているという意味ではない。

新しいトークンは、新しい本人の行為ではない

トークンの更新は、進んだように見えやすい。新しい発行時刻が記録され、応答が成功し、新しい文字列がクライアントに届く。しかし、それだけで利用者が直前に認証したことにはならない。

RFC 9068 の JWT アクセストークン・プロファイル は、トークン発行に関する情報と認証イベントに関する情報を分けている。同じ認可応答に由来するトークンでは、該当する更新や交換を経てもイベント情報が保持される。また、クライアントはアクセストークンの内容を解析することに依存してはならない。発行側とリソース側は形式を変更できるからだ。

したがって、クライアントが現在見えている内部情報を手掛かりに、その場しのぎの修復を行うべきではない。どの処理が必要なイベントを実際に起こし、誰がその証拠を評価するかについて、あらかじめ合意が必要である。

RFC 7662 のトークン・イントロスペクション は、権限を持つリソースがトークンの状態や情報を問い合わせる方法を提供する。RFC 9470 はこの経路にも認証コンテキストと時刻の情報を加える。ここでも、トークンが有効な状態にあることと、今回の操作に十分な認証が行われたことは同じではない。

どちらの経路で情報を受け取るかよりも、結果の意味を一致させることが先だ。新しい応答を得るためだけに利用者を呼び戻しても、必要な事実が変わらなければ負担は正当化しにくい。

拒否の詳しさにも価格がある

要求を具体的に説明すれば、正当なクライアントは次の行動を選びやすくなる。一方で、その説明はリソースから外へ出る情報でもある。

特定の利用者や操作だけに現れる要求は、その違いを相手に教える可能性がある。規格が述べるのはこのような危険の可能性であり、どこかの組織で攻撃が成功したという証拠ではない。必要なのは、説明に役立つ情報と、不要な推測を許す情報の境界を考えることだ。

トークンを検証する前に要求を返すことが許されていても、その順序がすべてのサービスに適しているわけではない。まだ適切なトークンを取得できると確認されていない相手にも、条件の一部を知らせることになる。

調査記録にも同じ考え方が必要である。問題を切り分けるために、トークンや個人属性を丸ごと保存するのが当然とは限らない。必要なコンテキストを提供できないのか、通信が失敗したのかを判断するための情報は、目的に応じて選ぶべきだ。

中断の数ではなく、成立した作業を見る

認証の要求回数が増えても、それだけで保護が向上したとは言えない。正当なポリシー変更、連携の不具合、実行不能な条件のいずれでも回数は増え得る。

必要な条件の下で、目的の作業が完了したかを見る。そのうえで、要件未達、状況の変わらない再試行、利用者の中止、承認済みの復旧を分けて把握する。これらは評価方法の提案であって、導入効果を測定した数値ではない。

逆に、中断を減らすことだけを目標にすると、必要な条件を取り去る誘惑が生じる。目指すべきなのは、最も厳しそうに見える手続きでも、最も滑らかな画面でもない。適切な要求を実行でき、できない場合にも責任の所在が分かるサービスである。