何度もお手数をおかけしてすみません。 > > 現実的にはパブリッククライアントにnonceの検証をさせてもIDトークンのリプレイアタックは防げません。 > 攻撃者がクライアントのプログラムを変更できるからです。 > > この攻撃/脅威についてより具体的に例示してもらえますか？ バックエンドサーバーはサービス運営者の管理下にあり、攻撃者はバックエンドサーバーで動くプログラムを改造することはできません。 攻撃者ができることは、APIに送るパラメータを工夫して(あるかもしれない)脆弱性をつくとか、大量のリクエストを送りつけてDOSするといったことくらいです。 しかし、SPAやモバイルアプリは攻撃者の手元のコンピューター上で動くプログラムなので、(簡単とは言いませんが)改造してセキュリティ機能を迂回させることができます。 具体的には、「認可レスポンスで得たIDトークンのnonce == 自分が認可エンドポイントに送ったnonce」というチェックコードが含まれるはずなので、そのコードを常にチェック成功するように変更できます。 あるいは、SPAやモバイルアプリを改造しなくても、バックエンドサーバーに対して正規アプリを装ったAPI呼び出しを行うこともできます。正規アプリを使わず、自作プログラムで盗んだIDトークンをバックエンドサーバーに送ってバックエンドサーバーとのログインセッションを確立し、バックエンドサーバーからユーザーの個人情報を盗み出したり、破壊的な操作(データの削除など)を行うことができます。 というのが、私が考える「バックエンドサーバーでなくパブリッククライアント(SPA/モバイルアプリ)がnonceの生成と検証を行う場合の攻撃/脅威」の具体例です。 質問に対する回答になっていますでしょうか？ 一方、nonceをサーバーで生成してサーバーで検証しているのであれば、 ・バックエンドサーバーがアプリ(SPA/モバイルアプリ)とのセッションに紐付いたnonceを生成し覚えておく ・アプリがバックエンドサーバーから得たnonceとともにOP認可リクエストを送る ・OPがユーザー認証を行いnonceを埋め込んだIDトークンをアプリに送る ・アプリがバックエンドサーバーにIDトークンを送る ・バックエンドサーバーは「アプリとのセッションに紐づくnonce」と「IDトークンに含まれるnonce」の一致と、同じnonceが過去に使われていないことを検証する という処理になり、バックエンドサーバーのプログラムが正しく実装されていれば、nonceと紐付いたセッションを持たない攻撃者は、盗んだIDトークンを使えません。 補足ですが ・攻撃者がセッション情報も盗める ・正規ユーザーのアプリがバックエンドサーバーにIDトークンを送る前に、攻撃者がIDトークンを送れる という状況であれば、バックエンドサーバーは偽のリクエストを受け入れてしまいますが、そもそもセッション情報を盗めるのであれば、ログイン後のユーザーになりすまして何でもできるので、IDトークン漏えい以上の危険な状況です。IDトークンのリプレイアタックの危険性を考えるときには、それは考えなくても良いと思います。