Skill.md検索

身元確認/eKYCの実装に必要な5つの決定項目（実施方法、申込みプロセス、外部サービス、verified_claims、必須スコープ）をヒアリングを通じて整理できます。 決定内容に基づいて、身元確認テンプレート設定用のJSON（テンプレートID、processes、execution、result.verified_claims_mapping_rules）を自動生成できます。 外部eKYCサービス（API連携）の認証方式、リクエスト/レスポンスマッピングを含めた実装設定ガイドが得られます。 認可サーバー拡張設定で身元確認を必須スコープ化し、セキュリティ要件を満たすための設定が簡単に実装できます。 身元確認申込みAPI（/v1/me/identity-verification/applications）と結果API（/v1/me/identity-verification/results）のアクセス権限設定がクリアになります。 本人確認機能をプロダクトに組み込みたいフィンテック・マーケットプレイス開発者 外部eKYCサービス（API連携）を初めて統合する認証実装担当者 セキュリティ要件として身元確認を必須化する設計をしているセキュリティアーキテクト idp-server経由の申込み方式と結果のみ登録方式の使い分けをしたい PM・企画者 身元確認/eKYCユースケースの設定ガイドです。ヒアリング項目は5項目（実施方法：idp-server経由/結果のみ登録、申込みプロセス：ステップ順序、外部eKYCサービス：APIエンドポイント・認証方式、verified_claims：保存情報・trust_framework、必須スコープ）で、各項目は身元確認テンプレートの設定に直結します。 設定対象は身元確認テンプレート設定（API: POST /v1/management/organizations/{org-id}/tenants/{tenant-id}/identity-verification-configurations）で、JSONスキーマでは必須項目（last_name、first_name、birthdate）と任意項目（email_address、address等）を定義します。execution セクションではhttp_requestで外部eKYCサービスのURLを指定し、OAuth 2.0認証（Password Grantフロー）でトークン取得後、body_mapping_rulesでリクエストボディをマッピングし、response_bodyからapplication_idを抽出して保存します。verified_claims_mapping_rulesで確認結果のデータ構造とtrust_framework、必須スコープ設定で認可要件が完成します。

Spring Boot で HTTP/REST API の実装レイヤーを正しいアーキテクチャパターンに従って構築できます。 Controller・Exception Handler・Filter・Spring Security 統合を適切に実装し、ビジネスロジックを HTTP ↔ DTO 変換に留めます。 アクセストークン検証・権限検証を実施し、OperatorPrincipal を SecurityContextHolder に正しくセットできます。 組織レベル API で URL から OrganizationIdentifier を解決し、マルチテナント環境に対応した実装ができます。 グローバル例外ハンドラーで例外を HTTP ステータス・エラーレスポンスに一貫して変換できます。 Spring Boot で OAuth/OIDC サーバーや管理 API を実装する開発者 マルチテナント環境でのセキュリティ・アクセス制御を適切に実装したい人 Bean 定義・Configuration・Filter の使い分けを正しく学びたい初〜中級開発者 Controller に ビジネスロジックが混在するのを防ぎ、関心の分離を徹底したい人 idp-server-springboot-adapter は HTTP/REST API の実装レイヤー。Controller（HTTP リクエスト → EntryService/Control-Plane API 呼び出し）、Configuration（Spring Bean 定義：DataSource・Repository）、Exception Handler（例外 → HTTP エラーレスポンス変換）、Filter（認証・CORS 前処理）を提供。鉄則：Controller にビジネスロジック一切含まず、HTTP ↔ DTO 変換のみ。モジュール構成：adapters/springboot/application/restapi/oauth（OAuth/OIDC エンドポイント）、control_plane/restapi（管理 API）、configuration（Spring Bean 定義）。Controller 命名：管理 API={Domain}ManagementV1Api、OAuth={OAuthV1Api 等}。実装パターン：HttpServletRequest を RequestAttributes に変換（Phase 1）→ control-plane API 呼び出し（Phase 2）→ HttpStatus を含むレスポンス生成（Phase 3）。@AuthenticationPrincipal OperatorPrincipal で認証ユーザー取得。ParameterTransformable implements で HttpServletRequest → RequestAttributes 変換メソッドを実装。

Identity Provider（IDP）サーバーの管理API層（Control Plane）を新規設計・実装し、システムレベルと組織レベルの階層化した管理機能を構築できます。 組織・テナント・クライアント・認証ポリシー・ユーザーなど複数のドメイン管理APIを統一されたパターンで実装できます。 73個のデフォルト管理者権限（DefaultAdminPermission）をidp:resource:action形式で定義し、細粒度のロールベースアクセス制御（RBAC）を実現できます。 全変更操作でDry-runモード（実行前の予行演習）をサポートし、本番リスクを低減した安全な管理操作ができます。 リクエスト/レスポンス変換パターンとHandler・EntryServiceの責務分離により、メンテナンス性の高い管理APIを構築できます。 マイクロサービス基盤でID認証・認可機能を担当するバックエンド開発者 SaaS・マルチテナント型IDPの構築・拡張を行うアーキテクト 管理API層の設計・実装ガイドラインを統一したいプロジェクトリード RBAC（ロールベースアクセス制御）の細粒度設計を必要とするセキュリティエンジニア Control Plane（管理API）はidp-serverの管理API層で、システム全体の設定管理・組織テナント管理・リソース構成を担当。2層構造（System Level・Organization Level）、Dry-runモード、73のデフォルト管理者権限を備える。モジュール構成は idp-server-control-plane（API契約）・idp-server-use-cases（EntryService）・idp-server-core（ドメインロジック）の3層。API設計パターンは ManagementApi→EntryService→Handler の流れで、各層が責務を分担。OrganizationManagementApi・TenantManagementApi・ClientManagementApi・AuthenticationPolicyManagementApi・UserManagementApi など各ドメイン別APIを実装。Handlerで Validator による検証後、Repositoryで永続化。ドキュメント参照：resource-overview.md・overview.md・system-level-api.md・organization-level-api.md。

Access Token、Refresh Token、ID Tokenの発行・検証・取消に関わる実装を正確に行えます。 OAuth 2.0の各グラントタイプ（Authorization Code、Refresh Token、Client Credentials、JWT Bearer Grant）に対応したトークン処理を効率よく開発できます。 Token Introspection（RFC 7662）によるトークン検証とToken Revocation（RFC 7009）によるトークン取消の実装をサポートします。 OpenID Connect対応のID Token発行処理を含む、エンタープライズグレードのトークン管理機能を構築できます。 OAuth 2.0やOpenID Connect実装に取り組んでいるバックエンド開発者 認証・認可レイヤーの既存コードを修正・拡張する必要があるエンジニア トークンライフサイクル管理（有効期限、キャッシュ戦略）の最適化に携わる者 マイクロサービス環境でトークンベースの認証基盤を構築する開発チーム 本スキルはモジュール構成、トークン発行処理、トークン検証・取消機能に関する詳細なリファレンスを提供します。idp-server-coreはトークンコアとして、TokenRequestHandler、OAuthTokenCreationServices、AuthorizationCodeGrantService、RefreshTokenGrantService、ClientCredentialsGrantServiceを含みます。トークン検証用にOAuthTokenQueryRepository、取消用にOAuthTokenCommandRepositoryがあります。idp-server-core-adapterはキャッシュ層を提供し、OAuthTokenCacheKeyBuilder、OAuthTokenCacheStoreResolver、OAuthTokenCommandDataSource、OAuthTokenQueryDataSourceで構成されます。idp-server-control-planeは管理APIレイヤーです。TokenRequestHandlerのメソッドシグネチャに基づいて、実装時の正確なAPI設計が可能になります。

ユーザー登録やAPI連携時に送信される入力データの構造・型・制約をJSON Schemaで自動検証できます。 必須フィールドの不足、型の不一致、フォーマット違反（メールアドレス形式など）を検出し、詳細なエラーメッセージを表示できます。 Identity Verification（本人確認申請）や外部API連携時の複雑なデータ検証ルールを、スキーマベースで一元管理できます。 テナント別にカスタマイズされたスキーマを定義でき、組織ごとに異なるユーザー属性要件に対応できます。 JSON Schema Draft 2020-12準拠の最新仕様に対応し、将来的な拡張性を確保できます。 ユーザー登録フォームのバリデーション機能を開発・保守しているバックエンド開発者 API設計時にリクエスト・レスポンスの構造を定義し、型安全性を保ちたいAPI開発者 Identity Verification（本人確認）など複雑なデータ検証ルールを実装する認証系エンジニア マルチテナント環境でカスタマイズ可能なバリデーションロジックが必要なシステム設計者 このSkillはJSON Schema Draft 2020-12に準拠し、libs/idp-server-platform/.../platform/json/schema/配下のモジュール群で実装。主要クラスは①JsonSchemaDefinition：スキーマ定義の保持と型管理、②JsonSchemaValidator：入力データとスキーマの照合検証、③JsonSchemaValidationException：フィールド別の詳細エラー情報。ユーザー登録時はIdPUserCreatorクラス内でJsonSchemaDefinitionが許可フィールドを定義し、AuthenticationInteractionRequestから該当フィールドを抽出して検証。スキーマ定義例として①ユーザー登録：email（メール形式）、name（1～100文字）、birthdate（YYYY-MM-DD形式）を必須に指定、②Identity Verification申請：document_type（enum値）、document_number（最小5文字）を必須。エラーレポートでは必須フィールド不足、型不一致、フォーマット違反、制約値超過（minLength/maxLengthなど）などをフィールド名付きで出力。

外部の認証 API を idp-server に接続：HTTP API 経由でユーザー名とパスワードを外部認証サービスに転送し、レスポンスからユーザー情報を自動マッピングできます。 既存認証基盤の活用：社内 LDAP・Active Directory・カスタム認証システムなど、既に構築された認証インフラを OIDC レイヤーとして再利用できます。 認証ポリシーをコード化：失敗回数やセッション有効期限、トークン有効期限などをテンプレートで定義し、環境変数で簡単にカスタマイズできます。 セキュリティ設定を一元管理：ブルートフォース防止（アカウントロック条件）、セッション・トークン有効期限をまとめて設定・検証できます。 Q&A による逆引き設定：「やりたいこと」から対応する設定キーを即座に調べ、実装できます。 エンタープライズ組織の認証統合担当者：既存の社内認証システムを OIDC 化したい マイグレーション・統合プロジェクトの PM：レガシー認証システムから段階的に移行したい OAuth 2.0 / OIDC の実装者：外部 API 連携による認証をテンプレート化したい セキュリティポリシーを定めたい組織：セッション・トークン有効期限をコードで管理したい 外部パスワード認証委譲ユースケース用の設定テンプレートとヒアリングガイドを提供します。テンプレートは config/templates/use-cases/external-password-auth/setup.sh で、カスタマイズ可能な環境変数（EXTERNAL_AUTH_URL、EXTERNAL_PROVIDER_ID、SESSION_TIMEOUT_SECONDS、ACCESS_TOKEN_DURATION など）を指定して実行できます。ヒアリング項目は7つ：外部認証サービス URL（影響: http_request.url）、外部プロバイダー ID（影響: user_mapping_rules）、アカウントロック条件（影響: failure_conditions/lock_conditions）、セッション有効期限秒数（影響: session_config.timeout_seconds）、AT/IDT/RT トークン有効期限秒数（影響: access_token_duration/id_token_duration/refresh_token_duration）。実験ガイド（EXPERIMENTS.md、EXPERIMENTS-http-requests.md）で設定変更による挙動変化を実際に確認でき、自動検証スクリプト（verify.sh）で設定妥当性を検証できます。

idp-serverのFIDO2/WebAuthn実装をWebAuthn4jライブラリを使って正確に進められるため、外部FIDO2サーバーに依存せず内部実装できます パスキー登録（Part A）と認証（Part B）の2フェーズフローを理解できるため、複雑な認可リクエストのpromptパラメータ（create/login/none）を適切に使い分けられます 登録時のアテステーション検証、認証時の署名検証など、セキュリティ面での実装ポイントを把握できます E2Eテストファイルやサンプルアプリのコード例を参照できるため、実装の妥当性を確認しながら進められます idp-serverでパスキー機能を実装している開発者 WebAuthn4jライブラリの使い方を学びたい人 FIDO2のセキュリティ検証（アテステーション、署名検証）に取り組む人 パスキー登録・認証フローのテストを書く人 idp-serverのFIDO2/WebAuthn実装コンテキストを定義します。実装ファイルはWebAuthn4jRegistrationManager（登録・アテステーション検証）、WebAuthn4jAuthenticationManager（認証・署名検証）、WebAuthn4jConfiguration（設定）で構成されます。ドキュメントは登録設定、認証設定、管理API、アテステーション検証の4ドキュメントで整理されます。認可リクエストのpromptパラメータは、createでユーザー登録、loginで再認証強制、noneでセッション有効時のコード発行を制御します。パスキー登録はprompt=createでユーザー登録→パスワード認証→WebAuthn Registration Challenge→Passkey登録、認証はprompt=loginで再認証→WebAuthn認証フロー。E2Eテストはmfa-05-fido2.test.js（基本フロー）とmfa-06-fido2-attestation-verification.test.js（検証）、サンプルUIはPasskeyRegistration/PasskeyAuthentication/UserInfoコンポーネントで実装されます。

FAPI 1.0 Baseline/AdvancedプロファイルやFAPI CIBAの実装・修正を体系的に進められます。 mTLS、PAR（Pushed Authorization Request）、JARM（JWT Secured Authorization Response Mode）などの高度なセキュリティ機能を実装できます。 リクエストのスコープとテナント設定に基づくFAPIプロファイル自動決定ロジックを理解し、適切に検証・実装できます。 63件のFAPI 1.0 Advanced OPテストとRFC要件のマッピングを参照して、OIDF認定基準を満たす実装を実現できます。 金融機関向けOAuth 2.0/OIDC認可サーバーを開発・保守するエンジニア FAPI準拠のセキュリティ実装が必要な決済・銀行系プロダクトの開発チーム OIDF（OpenID Foundation）認定を取得・維持する必要があるシステム担当者 mTLSやPAR、JARMなどの高度なセキュリティ機能の実装・検証を担当する開発者 FAPI（Financial-grade API）開発ガイドは、金融グレードセキュリティを実現するOIDC/OAuth 2.0プロファイル実装の詳細資料です。 FAPIには4つのプロファイルがあります：FAPI 1.0 Baseline（基本的なセキュリティ要件）、FAPI 1.0 Advanced（PAR/JARM/mTLS必須の高度な要件）、FAPI CIBA（CIBA+FAPI組み合わせ）、Sender-constrained Access Token（mTLSバインディング）。プロファイルは優先度順にリクエストのスコープとテナント拡張設定で自動決定されます（priority: fapi_advance_scopes > fapi_baseline_scopes > openid > デフォルト）。 モジュール構成は、idp-server-core-extension-fapiで FAPI Baseline/Advanced検証、mTLSクライアント認証を実装。idp-server-core-extension-fapi-cibaでFAPI-CIBA検証を実装。idp-server-coreのコアにPAR（OAuthPushedRequestParameters）とJARM（JarmCreatable）実装があります。詳細な実装ガイド、Gap分析、OPテストマッピング表が参考資料として提供されています。

ユーザー登録やID管理の実装時に、既存のコア機能（UserRegistrator、UserLifecycleManager等）を参照して開発できます。 ID Policy（ユーザーネーム、メールアドレス、電話番号など複数の識別方法）に基づいて、preferred_usernameを自動的に設定できます。 ユーザーステータス（未登録→登録→認証済み→ロック/無効化/削除）の遷移ルールに従って、ユーザーの状態管理を正確に実装できます。 NIST SP 800-63B準拠のパスワードポリシー（複雑さ要件、有効期限管理など）を組み込めます。 Federation経由でのユーザー登録（外部ID連携）にも対応した実装ができます。 認証・認可システムの開発に携わるバックエンド開発者 ユーザー管理画面やAPI仕様を設計しているシステム設計者 IDaaSやSSO基盤の構築に関わるインフラエンジニア セキュリティ要件に基づいてパスワードポリシーを定める企画・セキュリティチーム ユーザー管理の実装では、idp-server-core/openid/identity/ 配下のコアモジュールを活用します。主な構成要素は User.java（ユーザーエンティティ）、UserRegistrator.java（登録処理）、UserLifecycleManager.java（ライフサイクル管理）、UserVerifier.java（検証）、UserStatus.java（ステータス定義）です。UserRegistrator内の実装パターンでは、既存ユーザーの検索→更新判定→ID Policy適用→ビジネスルール検証→ステータス設定という流れで、registerOrUpdateメソッドが実装されています。リポジトリ層はUserCommandRepository（書き込み）とUserQueryRepository（読み込み）に分離され、ドメインロジック層とデータアクセス層が疎結合になっています。パスワードポリシー実装はPasswordPolicyValidator、PasswordChangeService等で管理され、NIST基準への準拠を維持しています。

ドキュメント内の技術的な説明が正確かどうか、公式ドキュメントやRFC（仕様書）で検証できます。 「1997年にServlet が登場」「HTTPの仕様は～」など、具体的な年代・仕様・歴史について、複数のソースで事実確認できます。 用語の使い分けに矛盾がないか、図と本文が一致しているか、一貫性をチェックできます。 誤った記述を見つけたとき、正確な修正案を提示し、ドキュメントの信頼性を高められます。 学習教材や技術ブログなど、多くの人が読むコンテンツの品質を事前チェックできます。 技術ライター・エディター：学習教材やブログの技術的な正確性を保証したい方 ドキュメント管理担当者：社内ナレッジベースやWikiの信頼性を維持したい方 開発リーダー：チームで共有するドキュメント・マニュアルの品質をレビューしたい方

Docusaurus（ドキュメント自動生成ツール）を活用して、マークダウンで書いたドキュメントを自動で整形・公開できます。日本語と英語の両言語対応で、グローバル対応も簡単です。 ローカル環境でドキュメントをプレビューしながら執筆でき、公開前に見た目を確認できます。 プロトコル仕様書やAPI参照資料（OpenAPI仕様書）を構造化して管理でき、開発者が必要な情報をすぐ見つけられます。 ドキュメントを読者層（初心者・開発者・運用者など）別にカテゴリ分けして整理し、誰もが自分に必要な情報だけを読めるようになります。 ファイル命名規則やフロントマターなどのテンプレートを統一し、チーム全体でドキュメント品質を保てます。 プロダクトのドキュメントを一元管理したいマーケティング・プロダクトマネージャー APIやプロトコル仕様書を分かりやすく公開したい開発リーダー 多言語ドキュメントの保守運用をシンプルにしたい国際展開企業 ドキュメント作成のルール化・自動化で品質を高めたいテクニカルライター