【実務・中級編】 OpenID Connect (OIDC) IDトークンを用いたユーザーアイデンティティ伝播 – ゼロトラスト＆エンタープライズセキュリティ実践ガイド

境界防御の幻想と、ZTNAがもたらす「アイデンティティファースト」の現実

ネットワークエンジニアとして長年企業のインフラを見続けていると、昔ながらの「社内ネットワーク＝安全地帯」という神話がいかに脆いかを痛感させられます。かつては、堅牢なファイアウォールで社内を囲み、一度VPNの門をくぐってしまえば、あとはフリーパスで内部のWebアプリケーションへアクセスできるのが当たり前でした。

しかし、リモートワークが当たり前になり、マルチクラウドへの移行が進んだ今、その境界線は霧のように消え去りました。社内も社外も関係なく、どこからでもアクセスが飛んでくる現代において、「一度通せば信用する」という境界型防御は、サイバー攻撃者にとって格好の踏み台でしかありません。

そこで主役に躍り出たのがゼロトラストネットワークアクセス（ZTNA）です。「何も信じるな、常に検証せよ（Never trust, always verify）」の原則に基づき、デバイスの健全性やユーザーのコンテキストを毎リクエストごとに評価します。

そして、このZTNAアーキテクチャの心臓部とも言えるのが、今回深掘りするOpenID Connect（OIDC）を用いたユーザーアイデンティティ伝播の仕組みです。「ユーザーが誰であるか」「どんな権限を持っているか」というコンテキストを、境界のゲートウェイからバックエンドのマイクロサービス群へいかに正確に引き回すか。ここを理解せずして、セキュアなAPI設計は語れません。

—

なぜアイデンティティ伝播（Propagation）が必要なのか？

現場の設計レビューで、よくこんなアンチパターンに出くわします。
「ZTNAゲートウェイが認証してくれるんだから、バックエンドのAPIサーバーは認証をサボってもいいよね」——これは非常に危険な発想です。

ZTNAゲートウェイがいくら強固にユーザーを認証しても、その背後にあるバックエンドAPIが「誰からのリクエストか」を知らなければ、データへのきめ細かなアクセス制御（認可）ができません。すべてのバックエンドサービスが共通の管理者権限で動いていたり、あるいはリクエストの送信元IPアドレスだけで信頼判断を下したりしているようでは、ゼロトラストの理念は砂上の楼閣となります。

ここで必要になるのが、「アイデンティティ伝播」です。
ユーザーがIdP（Identity Provider: Auth0, Azure AD / Entra ID, Keycloakなど）で認証を済ませた際に発行されたOIDC IDトークン（あるいはアクセストークン）を、ZTNAゲートウェイが受け取り、それを独自のカスタムヘッダーや、標準的な Authorization ヘッダーに加工してバックエンドへパスする。この一連の流れを確立することで、バックエンドAPIは「今、この瞬間にリクエストを発行しているのは、経理部の佐藤さんであり、その権限は〇〇である」というコンテキストを安全に把握できるのです。

—

OIDC IDトークンを用いた通信フローの全貌

実際のトラフィックがネットワーク上をどのように駆け巡るのか、そのシーケンスを見ていきましょう。ここでは、ユーザーがブラウザからZTNAゲートウェイ経由で、バックエンドのWeb APIを叩くシナリオを想定します。

[ブラウザ / クライアント]
       │
       │ (1) HTTPSリクエスト + セッションCookie / ベアラー
       ▼
[ZTNA ゲートウェイ (リバースプロキシ)]
       │
       ├─ (2) 未認証の場合: IdPへリダイレクトしてOIDC認証フロー実行
       │      IdPからIDトークン / アクセストークンを取得・検証
       │
       │ (3) トークンからユーザー情報（sub, email, roles等）を抽出
       │
       │ (4) バックエンド向けにヘッダーを付与して転送
       │     例: X-Forwarded-User: sato@example.com
       │     例: X-Id-Token: eyJhbGciOiJSUzI1NiIs...
       ▼
[バックエンド API サーバー]
       │
       └─ (5) 渡されたトークンやヘッダーを検証し、リソースへのアクセスを認可

フローのポイント

1. クライアントのファーストタッチ: ユーザーがZTNAゲートウェイへアクセスします。
2. IdPによる認証とトークン発行: セッションがない場合、ゲートウェイはIdPと連携してOIDC認証を行います。成功すると、IdPから署名済みのOIDC IDトークン（JWT）が返されます。
3. クレームの抽出と検証: ゲートウェイは、JWTのデジタル署名（JWKSを使用）を検証し、改ざんがないことを確認した上で、内部に含まれるクレーム（Claims）を読み取ります。
4. コンテキストの伝播: ゲートウェイは、バックエンドが処理しやすい形にアイデンティティ情報を変換し、HTTPヘッダーに載せてバックエンドへ転送します。

—

実務で使われる主要なパラメーター（JWTクレーム）

バックエンドへ伝播させる際、OIDC IDトークン（JWT）のペイロードに含まれる標準的なクレーム（パラメーター）を把握しておくことが不可欠です。現場でよく参照するキーを整理しておきます。

—

実装例：バックエンドAPIでの検証とコンテキストの受け取り

では、実際にZTNAゲートウェイからアイデンティティを受け取るバックエンド側の実装を見てみましょう。ここでは、軽量かつ堅牢なAPIを構築できるPythonのWebフレームワーク FastAPI を用いたサンプルコードを紹介します。

このコードでは、ZTNAゲートウェイが適切に検証・付与した X-Forwarded-User やカスタムヘッダーを受け取り、API内部でユーザーコンテキストとして利用する例を示しています。

from fastapi import FastAPI, Header, HTTPException, status
from typing import Optional
import jwt  # PyJWTライブラリ等を使用

app = FastAPI(title="Backend API with Identity Propagation")

# 本来はIdPの公開鍵（JWKS）を使って厳密に署名検証を行います
JWT_SECRET_OR_PUBLIC_KEY = "your-gateway-or-idp-public-key"
ALGORITHM = "RS256"

@app.get("/api/v1/secure-data")
def get_secure_data(
    x_forwarded_user: Optional[str] = Header(None),
    x_id_token: Optional[str] = Header(None)
):
    """
    ZTNAゲートウェイから伝播されたアイデンティティ情報を元に処理を行うエンドポイント
    """
    # 1. ゲートウェイ経由のアクセスであるかを検証（ヘッダーの存在チェック）
    if not x_forwarded_user:
        raise HTTPException(
            status_code=status.HTTP_401_UNAUTHORIZED,
            detail="認証コンテキストが欠落しています。ZTNAゲートウェイ経由でアクセスしてください。"
        )

    user_email = x_forwarded_user

    # 2. 必要に応じて生グルのIDトークン（JWT）を再検証・デコードして詳細なロールを取得
    user_roles = []
    if x_id_token:
        try:
            # 署名と有効期限の検証
            payload = jwt.decode(
                x_id_token, 
                JWT_SECRET_OR_PUBLIC_KEY, 
                algorithms=[ALGORITHM],
                options={"verify_aud": False} # 必要に応じて調整
            )
            user_roles = payload.get("roles", [])
        except jwt.PyJWTError as e:
            raise HTTPException(
                status_code=status.HTTP_403_FORBIDDEN,
                detail=f"IDトークンの検証に失敗しました: {str(e)}"
            )

    # 3. 認可のチェック（例: 'admin' ロールを持っているか）
    if "admin" not in user_roles:
        raise HTTPException(
            status_code=status.HTTP_403_FORBIDDEN,
            detail=f"ユーザー '{user_email}' にはこのリソースへのアクセス権がありません。"
        )

    # 4. ビジネスロジックの実行
    return {
        "status": "success",
        "message": "機密データへのアクセスが許可されました。",
        "context": {
            "user": user_email,
            "roles": user_roles
        }
    }

—

現場で役立つ実践的Tipsとトラブルシューティング

最後に、現場のインフラ構築やデバッグで必ず直面する、泥臭いトラブルと実践的なTipsをいくつか共有しておきます。

1. トークンの肥大化（Token Bloat）によるHTTPヘッダー制限の罠

IDトークンに多くのグループやカスタム属性を詰め込みすぎると、JWT自体のサイズが数キロバイトに膨れ上がります。これをそのまま Authorization: Bearer <token> やカスタムヘッダーに載せてバックエンドへ転送すると、NginxやEnvoy、あるいは前段のロードバランサー（ALB等）のHTTPヘッダーサイズ制限（例: large_client_header_buffers やデフォルトの8KB制限）に引っかかり、突然 431 Request Header Fields Too Large エラーが発生してシステムが沈黙します。

対策: IDトークンには最小限の識別子（sub や必要最小限のロール）だけを持たせ、詳細な属性情報はバックエンド側から認可サーバーへ別途問い合わせる（トークンイントロスペクション）か、ZTNAゲートウェイでクレームをフィルタリングして転送する設計にしましょう。

2. クライアントからの直接アクセス（バイパス）を防ぐネットワーク設計

「アイデンティティ伝播の仕組みを作った！」と安心しても、バックエンドAPIサーバーがパブリックなインターネットに直接露出していたり、社内LANのどのIPからでもポート番号を指定して直接叩ける状態になっていたりしては意味がありません。攻撃者がZTNAゲートウェイをバイパスして、適当な偽装ヘッダー（X-Forwarded-User: admin@example.com）を自前で付与してリクエストを送れば、バックエンドが簡単に騙されてしまいます。

対策: バックエンドAPIへの通信は、ZTNAゲートウェイ（またはEnvoy等のサービスメッシュ）からの通信のみを許可するようにファイアウォール（セキュリティグループ）を厳格にロックダウンしてください。さらに、ゲートウェイとバックエンド間で相互TLS（mTLS）を強制し、正規のゲートウェイ以外からのトラフィックを物理的・暗号学的にシャットアウトするのがプロのやり方です。

—

まとめ

OIDC IDトークンを用いたアイデンティティ伝播は、単なる「便利な機能」ではありません。それは、境界防御が崩れ去った現代のエンタープライズ環境において、「誰が何にアクセスしているか」をエンドツーエンドで担保するための生命線です。

正しい仕様を理解し、ゲートウェイとバックエンドの役割分担を明確に定義することで、セキュアかつ拡張性の高いゼロトラスト基盤を構築することができます。日々の運用や設計の現場で、ぜひこの原則を意識してみてください。あなたのインフラが、より堅牢で信頼性の高いものになることを願っています。