概要

ユーザーがOAuth SSO経由でJoomlaサイトにログインすると、IDプロバイダーはブラウザ経由で認証コードを返します。アプリケーションはそのコードをアクセストークンと交換します。これはほとんどの場合うまく機能しますが、問題があります。認証コードがアプリケーションに到達する前に誰かが傍受した場合、そのコードを使って自分でアクセストークンを取得できてしまうのです。

PKCE（Proof Key for Code Exchange）はこの問題を解決します。ログイン開始前に、アプリケーションはランダムな秘密鍵を生成し、そのハッシュ値をIDプロバイダに送信します。そして、トークンとコードを交換する際に、元の秘密鍵を保持していることを証明します。傍受された認証コードは、この証明がなければ役に立ちません。なぜなら、認証コードを保持しているのは元のアプリケーションだけだからです。

miniOrange Joomla OAuthクライアント拡張機能は、PKCEを標準でサポートしています。これを有効にすると、ユーザーのログイン方法を変更することなく、既存のSSO設定にこのセキュリティレイヤーを追加できます。

前提条件

JoomlaウェブサイトでPKCEで保護されたOAuth SSOを有効にするには、以下のものが必要です。

miniOrange OAuthクライアント拡張機能（Joomla用）

拡張機能をダウンロード

課題

OAuth SSOを実行しているほとんどのJoomlaサイトは、PKCEを使用しないデフォルトの認証コードフローを使用しています。これは多くのシナリオで問題ありませんが、理解しておくべきいくつかの重大なリスクも伴います。

認証コードはURLパラメータとしてブラウザを通過するため、ブラウザの履歴、サーバーログ、リファラーヘッダーなどに記録される可能性があります。そのため、たとえ短時間であっても、認証コードが漏洩するリスクが生じます。シングルページアプリケーションやブラウザベースのSSOフローなど、クライアントシークレットを安全に保管できないアプリケーションでは、認証コードがユーザーアカウントと、それを不正に入手した攻撃者との間の唯一の障壁となります。

最新のセキュリティベストプラクティスを反映したOAuth 2.1では、すべての認可コードフローにおいてPKCE（公開鍵認証）が必須となっています。SOC 2やISO 27001などの規格への準拠を目指す組織は、PKCEの導入がますます求められるようになっています。

PKCEがない場合、トークン交換を完了したクライアントがログインを開始したクライアントと同一であることを暗号学的に証明する手段もありません。この欠陥により、正確なセキュリティ監査を行うことが困難になります。

製品の導入

miniOrange OAuthクライアント拡張機能を使用してPKCEを設定するのは簡単です。設定手順は以下のとおりです。

1. 拡張機能でのPKCEの有効化： miniOrange拡張機能内のOAuthプロバイダー設定には、PKCEを有効にするための専用オプションがあります。このオプションを有効にすると、拡張機能はすべてを自動的に処理します。ログインの開始時にランダムなコード検証子を生成し、そこからハッシュ化されたチャレンジを作成し、認証リクエストの一部としてそのチャレンジをIDプロバイダーに送信します。トークン交換が行われると、元の検証子が認証コードとともに送信され、IDプロバイダーがそれらが一致することを確認できます。

2. コードチャレンジ方式の選択：この拡張機能は、S256とプレーンの2つの方式をサポートしています。S256方式では、チャレンジを送信する前にコード検証器をSHA-256でハッシュ化するため、元の秘密情報が送信されることはありません。プレーン方式では、検証器をチャレンジとして直接送信するため、実質的な保護は提供されません。稼働中のJoomlaサイトでは、S256方式が最適な選択肢であり、最新のほとんどのIDプロバイダーがS256方式をサポートしています。

3. IDプロバイダー構成の更新： IDプロバイダー側​​では、アプリケーション登録を更新してPKCEを必須にする必要があります。これは通常、アプリケーションを公開クライアントとしてマークするか、アプリ設定でPKCEの強制を有効にすることを意味します。具体的な手順はプロバイダーによって異なります。プロバイダーレベルでPKCEを必須にすることは重要です。なぜなら、認証コードが取得された場合でも、有効なコード検証ツールなしでトークン交換を試みると拒否されるからです。

4. フローのテスト： PKCEを有効にしたログインが成功した場合、ユーザーから見ると通常のSSOログインと全く同じように見えます。動作を確認するには、認証リクエストURLにcode_challengeおよびcode_challenge_methodパラメータが含まれていることを確認してください。セキュリティ保証をテストするには、コード検証ツールを使用せずにキャプチャした認証コードを再生してみてください。IDプロバイダはトークン交換をエラーで拒否するはずです。

結論

PKCEは、JoomlaのOAuth SSOで利用できる実用的なセキュリティ強化策の一つです。ユーザーに負担をかけることなく、実際の問題を解決できるからです。ログイン操作は全く変わりませんが、認証コードは傍受されたとしても無価値になります。PKCEはOAuth導入における標準規格となりつつあるため、miniOrange OAuth Client拡張機能でPKCEを有効にすることで、Joomla SSOの設定を最新のベストプラクティスに準拠させ、セキュリティレビューでの弁護も容易になります。

追加リソース

1. 区画化によるアクセス セキュリティ - Joomla! の OAuth プロトコル
2. Joomla での SAML と OAuth: どちらを選択すべきでしょうか?
3. 弊社のドキュメントをご覧ください