本番のシークレットやトークンではなく、プロバイダーのメタデータを貼り付けてください。宣言内容のみを確認し、プロバイダーへの接続やクライアント登録・リダイレクト許可リストの確認は行いません。
ブラウザ内でローカルに実行ブラウザおよびモバイルクライアントでは、PKCE 付きの Authorization Code を使用してください。このローカルチェッカーでは、プロバイダーへの登録、リダイレクト URI 許可リスト、同意ポリシー、実際のトークンの動作を確認することはできません。
/.well-known/openid-configuration が返す JSON を貼り付け、「OIDC 設定を確認」を押すと検査結果が表示されます。公開クライアント（Authorization Code）が必要とする項目を挙げ、統合前に直すべき問題と確認したい項目を分けて示します。クライアント ID とリダイレクト URI は任意で、入力するとローカル検査がより具体的になります。
PKCE のボタンは 48 バイトの乱数を取得して SHA-256 で要約し、コードベリファイア、S256 チャレンジ、state 値を表示します。処理はすべてこのタブ内の Web Crypto で行われ、貼り付けたメタデータは KivTools にも ID プロバイダーにも送信されません。
検査対象はブラウザーやモバイルクライアントが依存する項目です。issuer、authorization_endpoint、token_endpoint は絶対 URL である必要があり、本番は HTTPS、HTTP はループバックアドレスのみ許容します。トークン署名の検証には jwks_uri の宣言が必要です。Authorization Code フローには response_types_supported の code と grant_types_supported の authorization_code が含まれている必要があります。
公開クライアントで最も影響が大きいのは code_challenge_methods_supported です。PKCE がないと、モバイルや独自 URL スキームで横取りされた認可コードがそのまま交換され得ます。そのため plain のみの宣言や項目自体の欠落は、警告ではなく致命的な指摘として扱います。
「PKCE セットを生成」は crypto.getRandomValues から 48 バイトの乱数を取り、base64url で符号化して 64 文字のコードベリファイアを表示します。S256 チャレンジはこのベリファイアの SHA-256 要約を base64url にしたもの（43 文字）で、state 値は 24 バイトの乱数（32 文字）です。プロバイダーがコードを付けて戻したときに照合します。
使うべきは S256 です。チャレンジは認可リクエストに載り、ベリファイアはトークン要求までクライアントに留まるため、途中で横取りされたコードは交換できません。plain はベリファイア自体を URL に載せる方式で、plain しか対応しない文書がここで致命的な指摘になる理由です。
文書は貼り付けられた内容をそのまま読み取ります。プロバイダー側でクライアントが登録済みか、リダイレクト URI が許可リストにあるか、ユーザーにどの同意画面が出るか、エンドポイントが宣言どおりに動作するかは分かりません。それにはプロバイダーへの実際の認可リクエストが必要です。
指摘が出ない結果は、コピーしたメタデータが公開クライアントとして整合していることを意味し、統合が動作する証明ではありません。実際のフロー、トークンの寿命、更新の挙動はプロバイダーに対して検証が必要で、ここでのリダイレクト URI 検査はローカルでの完全一致の確認にすぎません。