Claimとは

詳細な図解

Claimを読むときの前提

Claimは、JWTなどのトークン内に入るユーザーID、発行元、対象API、期限、scope、role、グループなどの属性情報です。API認可、SSO属性連携、監査ログの利用者識別で使います。

実務では、iss、aud、exp、nbf、iat、sub、scope、role、groups、email、tenant、custom claim、発行元、更新タイミングを確認します。

証跡には、Claim名、値の意味、発行元、認可利用有無、マッピング先、更新元ディレクトリ、検証条件、過不足、利用しているAPIや画面を残します。

発行元と対象を確認する

Claimは、署名検証済みのトークン内にあって初めて信用できます。role=adminのような値が見えても、issuerやaudienceが想定と違えば使ってはいけません。

複数IdPや複数tenantを扱う場合、同じClaim名でも意味が違うことがあります。発行元と対象APIをセットで確認します。

• issとaudを確認する。
• 署名検証済みの値だけ使う。
• tenantや発行元ごとの意味を確認する。

表示用と認可用を分ける

メールアドレスや表示名は画面表示に便利ですが、認可判断に使うには不安定な場合があります。権限判断にはscope、role、groupsなど、運用で管理されたClaimを使います。

フロントエンドで見えるClaimを利用者が信頼できる権限根拠として扱うと危険です。API側で検証し、必要な権限を確認します。

• 表示用Claimと認可用Claimを分ける。
• API側で権限を検証する。
• フロント表示だけで認可しない。

権限過多と個人情報を棚卸しする

Claimにグループ一覧や個人情報を入れすぎると、トークンサイズ増加、漏えい時の影響、ログへの露出が大きくなります。必要な属性だけに絞ります。

権限Claimの付与元が人事情報、IdPグループ、アプリ内ロールのどれかを明確にします。更新遅延やキャッシュにより、退職・異動後も古い権限が残ることがあります。

• 不要なClaimを削除する。
• 権限付与元を記録する。
• 更新遅延とキャッシュを確認する。

変更証跡と引き継ぎ

Claim対応では、Claim名、意味、発行元、利用箇所、認可影響、マッピング変更履歴を残します。属性変更はログイン成功後の権限不一致として現れやすいです。

引き継ぎでは、IdP管理者、API担当、アプリ担当、関連語としてJWT、OIDC、Token、認可を残すと確認しやすくなります。

• claim mappingの変更前後を保存する。
• 権限判定に使うClaimを明記する。
• テストユーザーで過不足を確認する。

関連語

同じ主要カテゴリの用語

セキュリティ・認証の学習順

同じ主要カテゴリの用語をまとめて確認できます。現在の用語を起点に、前後の用語へ進むと文脈を保ったまま読み進められます。

InfraEngKit内の関連機能