💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

はじめに — 2026年になぜ SiteMinder を語るのか

2026年の IAM トレンドは明確です。passkeys がログインのデフォルトになりつつあり、[Keycloak 26.6](https://www.keycloak.org/docs/latest/release_notes/index.html) は FAPI 2.0 Final 対応や MCP(Model Context Protocol)認可サーバーとしての役割まで備え、AI エージェントのような non-human identity の管理が新しいテーマになっています。それなのに本記事は逆方向に進み、20年以上前の技術である Symantec SiteMinder を取り上げます。

理由は単純です。**今もなお、世界中の金融機関や大企業のイントラネットの奥深くで、SiteMinder が数百、数千のアプリケーションを保護しているからです。** モダン IAM への移行プロジェクトは、ほぼ例外なく「既存の SiteMinder 環境をどうするか」という問いから始まります。レガシーを知らなければ、マイグレーションの設計はできません。

本記事では SiteMinder の歴史、コアコンポーネント、セッションモデル、ポリシーオブジェクトモデル、リクエスト処理フロー、そしてヘッダーベース認証のセキュリティ含意まで、アーキテクチャの観点から深く解剖します。続編で扱う Keycloak マイグレーション戦略とハイブリッド共存パターンの基礎となる内容です。

SiteMinder の歴史 — Netegrity から Broadcom まで

SiteMinder の所有権の変遷は、それ自体がエンタープライズソフトウェア業界の歴史です。

| 時期 | 所有会社 | 備考 |

| --- | --- | --- |

| 1995〜2004 | Netegrity | WebSSO の概念を事実上確立した元祖製品 |

| 2004〜2018 | CA Technologies | CA SSO / CA Single Sign-On にリブランド |

| 2018〜現在 | Broadcom(Symantec ブランド) | Symantec SiteMinder に改名、12.8/12.9 系を維持 |

1990年代後半、Web アプリケーションが爆発的に増え、「アプリごとに個別ログイン」という問題が顕在化しました。Netegrity は**中央ポリシーサーバー + Web サーバーに組み込むエージェント**の組み合わせでこの問題を解決し、このアーキテクチャはその後の Oracle Access Manager、IBM Tivoli Access Manager(現 IBM Verify Access)、Ping Access など、すべての WebSSO 製品の原型となりました。

2026年現在の重要な事実をいくつか挙げます。

- 最新メジャーバージョンは **12.9** で、[Broadcom Tech Docs](https://techdocs.broadcom.com/siteminder) にドキュメントがあります。

- 12.8.04 は 2023年12月に EOS(End of Service)を迎えました。旧バージョンを使う組織はサポート空白のリスクに晒されています。

- Broadcom は Policy Server と Access Gateway の **Kubernetes コンテナデプロイ**をサポートし、モダナイゼーションの流れに対応しています。

- それでも、ライセンスコスト、閉鎖的なエコシステム、標準プロトコル中心の設計でないことから、多くの組織が [Keycloak](https://www.keycloak.org/documentation) などへの移行を検討しています。

全体アーキテクチャ概要

SiteMinder のアーキテクチャは大きく5つのコンポーネントで構成されます。

+---------------------------+

| Admin UI |

| (ポリシー管理コンソール、WAMUI)|

+------------+--------------+

| 管理/設定

+----------------+ TCP 44441-3 +---------------------------+

| Web Agent | <-----------> | Policy Server |

| (Webサーバー | (Agent API) | - 認証(IsAuthenticated) |

| モジュール) | | - 認可(IsAuthorized) |

+-------+--------+ | - セッション/監査/鍵管理 |

| +------+-------------+------+

| 保護 | |

v | |

+----------------+ +-------v-----+ +-----v--------+

+----------------+ +-------------+ +--------------+

+-------v--------+

| User Store |

| (AD/LDAP/RDBMS)|

+----------------+

Policy Server — 頭脳

Policy Server は SiteMinder の中核的な意思決定エンジンです。役割は次のとおりです。

- **認証判断**: ユーザーが提示したクレデンシャル(フォーム、証明書、Kerberos など)を User Store と照合して検証します。

- **認可判断**: 認証済みユーザーが特定リソースにアクセスできるか、ポリシーを評価します。

- **セッション管理**: セッションチケットの発行、有効性検証、idle/max タイムアウトの適用。

- **鍵管理**: SMSESSION クッキーを暗号化する Agent Key の生成とロールオーバー。

- **監査ログ**: 認証/認可イベントを監査ストアに記録。

Policy Server は従来 TCP 44441(アカウンティング)、44442(認証)、44443(認可)ポートで Web Agent と通信し、新しいバージョンでは単一ポートに多重化されます。高可用性のために複数台をクラスタ化し、Agent 側でフェイルオーバーさせる構成が標準トポロジーです。

Web Agent — 手足

Web Agent は Apache、IIS、(Access Gateway 経由の)Nginx 系プロキシなどの Web サーバーにインストールされる**インプロセスモジュール**です。すべての HTTP リクエストをインターセプトして以下を行います。

1. リクエスト URL が保護対象かを Policy Server に問い合わせ(IsProtected)

2. 保護対象なら SMSESSION クッキーの存在と有効性を確認

3. クッキーがない、または無効なら、認証スキームに従いログインページへリダイレクト

4. 認証/認可に成功したら、ユーザー情報を HTTP ヘッダーに載せてバックエンドアプリへ転送

Agent は性能のためにポリシー判断を**ローカルキャッシュ**します。Agent Cache の TTL 設定は、セキュリティ(ポリシー変更の即時反映)と性能(Policy Server の負荷)のトレードオフです。

Policy Store — ポリシーの保管庫

realm、rule、policy、response などすべてのポリシーオブジェクトが保存される場所です。伝統的には LDAP ディレクトリ(CA Directory など)が使われ、RDBMS もサポートされます。Policy Store はすべての Policy Server が共有する単一の信頼できる情報源(single source of truth)です。

Session Store — サーバーサイドセッション(オプション)

SiteMinder のセッションは基本的に**すべてがクッキーの中に入った stateless モデル**です。しかし、次の機能を使うにはサーバーサイドの Session Store が必要です。

- 管理者による強制セッション終了(session revocation)

- 同時セッション数の制限

- SAML フェデレーションのアーティファクト/セッション状態の保存

Admin UI — 管理コンソール

WAMUI(Web Access Management UI)と呼ばれる Web ベースの管理コンソールで、ポリシーオブジェクトの作成/変更と Agent 設定を担当します。大規模環境では Perl/Java ベースの Policy Management API でポリシーをコードとして管理することもあります。

SMSESSION クッキーとセッションモデル

SiteMinder SSO の心臓部は **SMSESSION クッキー**です。

GET /portal/dashboard HTTP/1.1

Host: intranet.example.com

Cookie: SMSESSION=Av3qB9x...暗号化されたセッションチケット...K2w=

動作原理を整理すると次のとおりです。

- ユーザーが最初の認証に成功すると、Policy Server が**セッションチケット**(session spec)を生成します。チケットにはユーザー DN、認証時刻、認証レベル、idle/max タイムアウト情報が入っています。

- チケットは Policy Server が管理する**対称鍵(Agent Key)**で暗号化され、SMSESSION クッキーとしてブラウザへ送られます。

- 同じクッキードメイン(例: .example.com)内の別のアプリにアクセスすると、そのアプリの Web Agent がクッキーを Policy Server に送って復号/検証し、有効なら再ログインなしで通過させます。これが SSO の実体です。

- Agent Key は定期的に**ロールオーバー**されます。Policy Server は現在の鍵と以前の鍵を併せて保持し、ロールオーバー中も既存クッキーを検証できるようにします。

このモデルの特性をモダンなトークンベース(OIDC)モデルと比較すると次のとおりです。

| 項目 | SiteMinder SMSESSION | OIDC(Keycloak など) |

| --- | --- | --- |

| トークン形式 | 独自の暗号化バイナリクッキー | 標準 JWT(署名ベース) |

| 検証方式 | Agent が Policy Server に問い合わせ | クライアントが署名を自己検証可能 |

| SSO 範囲 | クッキードメイン単位 | IdP セッション + リダイレクト、ドメイン非依存 |

| セッション失効 | Session Store 使用時に可能 | トークン寿命 + back-channel logout |

| 標準性 | 非標準(ベンダーロックイン) | IETF/OpenID 標準 |

| API/モバイル | 不向き(ブラウザクッキー前提) | 適合(Bearer トークン) |

クッキードメイン単位の SSO という点が重要です。異なるドメイン間の SSO が必要な場合、SiteMinder は別途フェデレーション機能(SAML)やクッキープロバイダー構成を持ち出す必要があります。

ポリシーオブジェクトモデル — realm、rule、policy、response

SiteMinder の認可モデルを理解するには4つのオブジェクトを知る必要があります。このオブジェクトモデルは、マイグレーション時に Keycloak の概念へマッピングすべき対象でもあります。

Domain (ポリシードメイン)

├── Realm: 保護するリソース領域 (URL prefix + 認証スキーム)

│ 例) Agent=intranet-agent, Resource=/hr/*

│ AuthScheme=Forms, SessionTimeout=30m

│

├── Rule: realm 内での操作マッチング

│ 例) GET,POST on /hr/payroll/* (Web Agent action)

│ OnAuthAccept イベントルール

│

├── Policy: Rule + ユーザー(グループ/DN フィルタ)の結合

│ 例) "HR-Payroll-Access" =

│ Rule(/hr/payroll/*) + LDAP group cn=hr-staff

│

└── Response: ポリシーマッチ時の付加動作

例) HTTP ヘッダー SM_USER, SM_USERGROUPS の注入、

リダイレクト、クッキー設定

各オブジェクトをもう少し詳しく見ていきます。

Realm

保護対象リソースの束です。特定の Agent(または Agent グループ)とリソースフィルタ(URL prefix)、そして**認証スキーム**を結びつけます。realm 単位でセッションの idle/max タイムアウト、認証レベル(protection level)を指定します。「この URL 領域はフォーム認証で保護し、セッションは30分」という宣言が realm です。

Rule

realm 内部で具体的なリソースパターンと HTTP アクション(GET、POST、PUT など)をマッチングします。Web Agent action 以外にも OnAuthAccept、OnAuthReject、OnAccessAccept のような**イベントルール**があり、認証の成功/失敗時点で response を発動させられます。

Policy

rule と**ユーザー集合**を結びつけるオブジェクトです。ユーザー集合は LDAP グループ、組織単位(OU)、DN フィルタ、動的な式で定義します。時間制約(平日 09-18 時のみ許可)や IP 制約も policy に設定できます。

Response

ポリシーがマッチしたときに Web Agent へ送られる指示です。最も一般的な用途が **HTTP ヘッダー注入**です。バックエンドアプリはこのヘッダーを読んで「誰がログインしているか」を知ります。このメカニズムが SiteMinder エコシステムの祝福であり呪いでもあるのですが、後で詳しく扱います。

認証スキーム(Authentication Schemes)

realm ごとに指定する認証スキームは非常に多様です。代表的なものを整理します。

| スキーム | 説明 | ユースケース |

| --- | --- | --- |

| Basic | HTTP Basic 認証 | レガシー社内ツール、API 的呼び出し |

| HTML Forms (FCC) | .fcc ファイルベースのカスタムログインフォーム | 最も一般的な社員ポータルログイン |

| X.509 Certificate | クライアント証明書(mTLS) | 高セキュリティ金融業務 |

| Windows Authentication | Kerberos/NTLM 統合認証 | AD 環境のデスクトップ SSO |

| SAML 2.0 | フェデレーションパートナーからの assertion | 外部 IdP 連携 |

| RADIUS / OTP | 二要素認証の組み合わせ | step-up 認証 |

| Custom (SDK) | Java/C SDK で作成したカスタムスキーム | 社内独自の認証体系 |

特筆すべきは **protection level** の概念です。スキームごとに 1〜1000 の保護レベルを付与し、ユーザーが低レベルのスキームで認証した状態で高レベルの realm にアクセスすると、再認証(step-up)を要求します。モダン IAM の ACR/AMR、step-up authentication の概念の祖先にあたります。

FCC(Forms Credential Collector)ファイルは次のような独特な形式のテンプレートです。

@username=%USER%

@smretries=2

リクエスト処理フロー — Agent はどうやってインターセプトするのか

未認証ユーザーが保護リソースにアクセスするシナリオを、ステップごとに追ってみます。

ブラウザ Web Agent Policy Server User Store

| | | |

|--1 GET /hr/----->| | |

| |--2 IsProtected?---->| |

| |<--Yes, Forms scheme-| |

| | (3) SMSESSION なし | |

|<-4 302 login.fcc-| | |

| ?TARGET=/hr/ | | |

| | | |

|--5 POST 資格情報->| | |

| |--6 Login(user,pw)-->|--7 LDAP bind---->|

| | |<--OK-------------|

| |<-8 チケット+Response--| |

|<-9 Set-Cookie:--| | |

| SMSESSION=... | | |

| 302 /hr/ | | |

| | | |

|--10 GET /hr/---->| | |

| (SMSESSION 付き)|--11 Validate+------>| |

| | IsAuthorized? | |

| |<--OK + ヘッダー指示---| |

| | (12) SM_USER など | |

| | ヘッダー注入後アプリ呼出| |

|<-13 200 OK------| | |

主要なステップを押さえると次のとおりです。

1. **IsProtected**: Agent が URL がどの realm に属するか、どの認証スキームが必要かを問い合わせます。結果は Agent にキャッシュされます。

2. **Credential Collection**: Forms スキームなら login.fcc にリダイレクトし、元々アクセスしようとした URL は TARGET パラメータとして保存します。

3. **認証とセッション発行**: Policy Server が User Store(主に AD/LDAP)に bind を試みて検証し、成功するとセッションチケットを作って暗号化し、SMSESSION クッキーとして送ります。

4. **認可とヘッダー注入**: 以降のリクエストごとに(キャッシュ TTL 内ではキャッシュで)IsAuthorized を評価し、マッチした policy の response に従って HTTP ヘッダーを注入し、バックエンドへ転送します。

同じクッキードメインの2番目のアプリにアクセスすると、4〜9 のステップは省略され、SMSESSION の検証だけで通過します。ユーザーから見れば「一度のログインですべてのイントラネットアプリにアクセス」が実現するのです。

HTTP ヘッダーベースのユーザー伝搬 — SM_USER とセキュリティ含意

SiteMinder の保護下にあるバックエンドアプリが受け取るリクエストはおおよそ次のようなものです。

GET /hr/payroll/list HTTP/1.1

Host: hr-app.internal.example.com

SM_USER: jdoe

SM_USERDN: uid=jdoe,ou=people,dc=example,dc=com

SM_USERGROUPS: hr-staff^payroll-admin

SM_SESSIONID: aBcD1234...

SM_AUTHTYPE: Forms

X-Custom-Empno: 100234

アプリは認証ロジックなしに SM_USER ヘッダーを読むだけで済みます。Java サーブレットなら次のようなコードが典型です。

// レガシーアプリの典型的な SiteMinder 連携コード

public class SmUserFilter implements Filter {

@Override

public void doFilter(ServletRequest req, ServletResponse res,

FilterChain chain) throws IOException, ServletException {

HttpServletRequest request = (HttpServletRequest) req;

String user = request.getHeader("SM_USER");

if (user == null || user.isEmpty()) {

((HttpServletResponse) res).sendError(401, "No SSO context");

return;

}

// ヘッダー値をそのまま信頼してセキュリティコンテキストを構成

SecurityContextHolder.setPrincipal(new SmPrincipal(user));

chain.doFilter(req, res);

}

このパターンはアプリ開発を極度に単純にし、だからこそ数千の社内アプリがこのように書かれました。しかし、深刻なセキュリティ上の前提が隠れています。

Header Injection の攻撃面

**アプリがヘッダーを無条件に信頼するということは、Web Agent を迂回してアプリに直接到達できる経路が一つでもあれば、即座に認証バイパスになるということです。**

Agent を迂回してアプリサーバーに直接アクセスできるネットワークなら

攻撃者がヘッダーを偽造するのに curl 一行で十分です

curl -H "SM_USER: ceo" -H "SM_USERGROUPS: payroll-admin" \

http://hr-app.internal.example.com:8080/hr/payroll/list

したがって、ヘッダーベースのアーキテクチャでは次が必須です。

- **ネットワーク分離**: アプリサーバーは Agent がインストールされた Web サーバー/ゲートウェイからのみアクセス可能にする(ファイアウォール、セキュリティグループ)。

- **ヘッダーストリッピング**: Agent/プロキシは外部から入ってきた SM_USER 系ヘッダーを必ず除去し、自前の値で上書きする。

- **相互認証**: 可能ならゲートウェイとアプリの間に mTLS や共有シークレットヘッダーを追加して出所を検証する。

このセキュリティ含意はマイグレーション後もそのままついてきます。oauth2-proxy のようなモダンプロキシでヘッダー注入パターンを再現する場合も、同じ分離原則を守る必要があります。詳しくは [OWASP の認証ガイド](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html)も参考になります。

ヘッダーエンコーディングの落とし穴

運用していると出会う古典的な落とし穴もあります。

- SM_USERGROUPS の区切り文字がキャレット(^)のため、カンマを前提としたパースコードは壊れます。

- 日本語など非 ASCII のユーザー属性が RFC 2047 エンコードで送られてきて、アプリが壊れた文字列を受け取ることがあります。

- Agent 設定の LegacyVariables の有無によって、ヘッダー名が SM_USER か SMUSER かが変わります — マイグレーションのインベントリ調査で必ず確認すべき項目です。

Federation — SAML で外の世界とつながる

SiteMinder は純粋な WebSSO 以外にフェデレーション機能も備えています。Federation Partnership 構成により、SiteMinder を [SAML 2.0](https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf) の IdP または SP として動作させられます。

- **IdP として**: SMSESSION を持つユーザーに対して SAML assertion を発行し、外部 SaaS(Salesforce など)やパートナーに SSO を提供します。

- **SP として**: 外部 IdP が発行した assertion を受け取り、SMSESSION に変換します。この方向がマイグレーションの共存設計で決定的に重要です — **Keycloak を IdP、SiteMinder を SP とすれば、モダンスタックでログインしたユーザーがレガシーアプリ領域へ途切れなく移動できるからです。**

- OIDC サポートも後期バージョンで追加されましたが、SAML に比べて機能の幅が狭く、現場での採用も限定的です。

フェデレーション機能を使うには Session Store が事実上必須となり、証明書/メタデータ管理の負担も加わります。

12.9 の現状とコンテナ化の流れ

Broadcom は SiteMinder を捨てていません。12.9 系での変化は次のとおりです。

- **コンテナデプロイ**: Policy Server、Access Gateway、Admin UI の Docker イメージと Kubernetes Helm チャートが提供され、VM ベースの手動インストールの代わりに宣言的デプロイが可能になりました。

- **Access Gateway 中心への転換**: 個々の Web サーバーごとに Agent を組み込む代わりに、中央のリバースプロキシ型ゲートウェイ(Access Gateway、旧 Secure Proxy Server)に保護を集約するパターンが推奨されます。興味深いことに、これはモダンアーキテクチャのゲートウェイパターンと収斂する方向です。

- **REST API の拡充**: ポリシー管理用 REST API が強化され、IaC 的な自動化が可能になりました。

しかし、本質的な限界は残ります。SMSESSION は依然として非標準であり、ライセンスは依然として高価であり、新しいエンジニアが学びたがらない技術スタックだという点です。

なぜ今も金融機関や大企業に残っているのか

技術的に劣って見えるのに、なぜ消えないのでしょうか。現場の理由は合理的です。

1. **アプリ数の問題**: 大手銀行のイントラネットには SiteMinder が保護するアプリが 200〜2000 規模で存在します。その多くはソースコードの修正が不可能な(ベンダー廃業、保守契約終了)アプリです。

2. **ヘッダーへの結合度**: アプリが SM_USER ヘッダーに直接結合しているため、IdP を入れ替えるだけでは済まず、アプリの認証連携部分に手を入れる必要があります。

3. **安定性の実績**: 20年間検証されたシステムに対して「動いているのになぜ変えるのか」という慣性が強い。金融機関は特に可用性インシデントに敏感です。

4. **規制と監査**: 認証体系の変更にはセキュリティ審査、監督当局への報告など手続きコストが大きい。

5. **組織の知識**: 数千のポリシーの意味を知る人が退職すれば、マイグレーションどころか現状維持さえ難しくなります — 逆説的に、これこそ移行を急ぐべき理由でもあります。

結局、ほとんどの組織が選ぶ道はビッグバン置き換えではなく、**数年にわたるハイブリッド共存**です。Keycloak のようなモダン IdP を隣に立て、SAML/OIDC ブリッジとプロキシパターンでアプリをひと固まりずつ移していくのです。この戦略は続編で詳しく扱います。

運用観点チェックリスト — SiteMinder 環境を引き継いだら

マイグレーションの前に、現在運用中の SiteMinder 環境で最低限確認すべきことです。

Policy Server の状態確認 (smpolicysrv プロセスとポート)

ps -ef | grep smpolicysrv

netstat -an | grep 44443

Web Agent ログで認証失敗パターンを確認

tail -f /opt/ca/webagent/log/WebAgent.log | grep -i "denied\|reject"

ポリシーストアのエクスポート (XPSExport — インベントリ作成の出発点)

XPSExport policy-export.xml -xb -vT

Agent 設定のダンプ (ACO パラメータの確認)

Admin UI または XPSExplorer で AgentConfigObject を照会

- **Agent Key のロールオーバー周期**が設定どおりに回っているか、ロールオーバー時に間欠的な 401 が発生していないか確認します。

- **Agent Cache TTL** が長すぎてポリシー変更が反映されない問題がないか点検します。

- 証明書の期限切れ(フェデレーション署名証明書、Policy Server 間通信)は古典的な障害原因です。

- XPSExport の出力はマイグレーションインベントリの一次資料になります。まず realm/rule/policy/response の数と、使用中の認証スキームの分布を抽出してみてください。

アンチパターン集

現場でよく見かける SiteMinder のアンチパターンです。新システム設計時の反面教師として有用です。

- **万能 realm**: ルート(/)に一つの realm を設定し、すべてのアプリを一つのポリシーで保護 — アプリごとの差別化されたセキュリティが不可能になり、マイグレーション単位の分離も困難になります。

- **response の乱発**: アプリごとにカスタムヘッダー response を数十個作り、ポリシーストアがアプリ設定の保管庫のように変質したケース。ヘッダーインベントリなしには、どのアプリがどのヘッダーに依存しているか分からなくなります。

- **OnAuthAccept ルールにビジネスロジック**: 認証イベントルールでユーザー属性を操作したり外部システムを呼び出したりする構成 — 障害伝播の原因になります。

- **Session Store なしの強制ログアウト要求**: stateless クッキーモデルでは「特定ユーザーの即時遮断」は不可能なのに、これを Agent キャッシュのフラッシュで真似ようとして全体の性能低下を引き起こした事例があります。

- **文書化されていない FCC カスタマイズ**: login.fcc に JavaScript で実装されたパスワードポリシーやお知らせポップアップなど — マイグレーション時に見落としやすい隠れた要件です。

おわりに

SiteMinder は「中央でのポリシー決定 + エッジでの執行 + ヘッダーベースのアイデンティティ伝搬」という、その後のすべての WebSSO、さらにはモダンなサービスメッシュ認可パターンにまでつながるアーキテクチャの原型を作りました。2026年の視点で見れば、非標準クッキー、ヘッダー信頼モデル、ベンダーロックインという限界は明白ですが、その設計意図を理解することはレガシーの軽視ではなく、マイグレーション成功の前提条件です。

次の記事では、本記事の内容を土台に **SiteMinder から Keycloak へのマイグレーション戦略** — インベントリ、オブジェクトマッピング、共存アーキテクチャ、漸進的パスワードキャプチャまで — を実戦ロードマップのレベルで扱います。

参考資料

- [Broadcom SiteMinder Tech Docs](https://techdocs.broadcom.com/siteminder)

- [Broadcom Symantec SiteMinder 製品ページ](https://www.broadcom.com/products/identity/siteminder)

- [SAML 2.0 Core 仕様 (OASIS)](https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf)

- [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html)

- [RFC 6749 — The OAuth 2.0 Authorization Framework](https://datatracker.ietf.org/doc/html/rfc6749)

- [RFC 9700 — Best Current Practice for OAuth 2.0 Security](https://datatracker.ietf.org/doc/html/rfc9700)

- [OAuth 2.1 draft (draft-ietf-oauth-v2-1)](https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/)

- [Keycloak 公式ドキュメント](https://www.keycloak.org/documentation)

- [Keycloak リリースノート](https://www.keycloak.org/docs/latest/release_notes/index.html)

- [OWASP Authentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html)

- [W3C WebAuthn Level 3](https://www.w3.org/TR/webauthn-3/)