境界線の守り方 ――
JWT認証とセッション管理で実現する「ガチ」の防衛術

2026.06.09

前回の記事では、外部サーバを使って「30秒の壁」を突破する方法をご紹介しました。

しかし、システムを外部と繋ぐ以上、いかに「正当なアクセス」を担保するかが極めて重要になります。今回は、システム開発案件に求められる高水準のセキュリティ要求に対し、どのような技術スタックで応えたのかを解説します。

■【課題】外部API連携で生まれる防御のすき間

SPIRAL®という「守られた箱」の外に処理を出す以上、単なるAPIキー認証だけでは不十分です。

「SPIRAL®の認証エリアから行われた正当な操作であること」を外部サーバ側でも確認し、さらにリクエスト内容の改ざんや不正な直接アクセスを防ぐ必要がありました。

多くの開発現場では、APIキー認証やJWTの署名検証だけで十分と考えられがちです。多くの開発現場では、APIキー認証やJWTの署名検証だけで十分と考えられがちです。

しかし、実際には以下のようなリスクが存在します：

これらの問題を個別に対処しただけでは不十分で、複数のセキュリティレイヤーを組み合わせた「多層防御」が必要なのです。

本案件では、自治体DXにふさわしい信頼性を担保するため、以下の4つの対策を組み合わせました。

外部サーバ側では、受け取ったJWTの署名検証を行うだけでなく、そのトークンを用いてSPIRAL® APIを処理時点で再照会する仕組みを構築しました。

「形式上正しいトークンであること」にくわえて、「SPIRAL®側の認証状態と整合していること」を確認することで、不正なリクエストを受け付けにくい構成としています。

処理対象の特定に、クライアント側から推測可能なIDを使用することをやめ、サーバサイドのセッションに紐付けた、推測困難な管理方式へ移行しました。

インポートファイルなどは推測困難なランダムトークンで管理し、処理後の一時ファイルや管理用DBレコードは速やかに削除します。

また、正常終了・異常終了を問わず後処理が実行されるよう、終了時処理を組み込み、不要なデータが残りにくい設計としました。

外部サーバに渡す情報は必要最小限に絞り、処理内容の判断はできる限りPHP側で行う構成としました。

やむを得ずパラメータを受け取る場合も、ホワイトリスト形式で許可された値のみを処理対象とし、想定外の値によって処理範囲が広がらないよう制御しています。

本案件では、専門家による手動脆弱性診断を品質ゲートとして設定しました。

SPIRAL®自体は堅牢な基盤である一方、一般的な自動診断だけでは、認証エリア内の画面遷移や外部サーバ連携を含む実際の業務フローまで十分に確認しきれない場面があります。

そのため、自動診断だけに頼るのではなく、SPIRAL®の仕様や構成を踏まえた手動診断・コード精査を実施。診断結果をフィードバックしながら、外部連携部分の安全性を高めました。

SPIRAL®を活用した開発におけるJWT認証とセッション管理について、前後編に分けてご紹介しました。

認証まわりの設計は、利用者の利便性とシステムの安全性のどちらにも関わる重要な領域です。要件や運用条件に応じて適切な仕組みを選び、無理のない形で実装していくことが大切です。

最後までお読みいただきありがとうございました。
SPIRAL®を使った開発についてのご相談はこちらからどうぞ。

▶ ご相談・お問い合わせ
https://www.wan55.co.jp/contact/

▶ 関連サービス
SPIRALカスタマイズ：https://www.wan55.co.jp/spiral/

▶ 関連コラム（コーポレートサイト）
https://www.wan55.co.jp/news/column/