LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

認証基盤・IDaaS連携開発とは——外注判断の前に押さえる範囲と標準規格

認証基盤・IDaaS連携開発の外注とは、OAuth 2.0やOpenID Connect（OIDC）・SAMLといった標準プロトコルを用いたシングルサインオン（SSO）や多要素認証（MFA）の実装、およびOkta・Microsoft Entra ID・Auth0などのIDaaS（Identity as a Service）製品の設定・連携開発を、専門知識を持つ外部パートナーに委託する取り組みです。

社内に認証エンジニアがいない企業でも、クラウドサービスの増加やゼロトラストセキュリティへの移行に伴い、認証基盤の刷新が急務となっています。しかし、実装には複数のプロトコル仕様と製品知識が組み合わさるため、内製は難しい領域です。

OAuth 2.0/OIDC/SAMLの役割分担

認証基盤で使われる主要プロトコルは3つです。それぞれ役割が異なるため、開発範囲を委託先に伝える前に整理しておく必要があります。

OAuth 2.0（RFC 6749、IETF発行・2012年10月）^*1は、第三者アプリケーションがユーザーに代わってAPIにアクセスするための「認可フレームワーク」です。ユーザーの認証情報を直接渡さずに、アクセストークンを介してリソースへのアクセスを委譲できます。

OpenID Connect（OIDC）（OpenID Foundation・2023年12月改訂版^*2）は、OAuth 2.0を基盤として「ユーザー認証」を担うプロトコルです。IDトークン（JWT形式）によってユーザーの身元情報をアプリケーション間で署名検証済みの状態で伝達します。SSOをWebアプリやモバイルアプリに実装する際の標準として広く採用されています。

SAML 2.0（2005年策定）は、企業間・エンタープライズ向けのSSO標準として普及しています。XMLベースのアサーション（デジタル署名付き認証情報）をIDプロバイダーとサービスプロバイダー間で交換する仕組みで、ERPや社内ポータルとの連携で広く使われます。^*3

IDaaSとは何か——Okta・Entra ID・Auth0が担う機能

IDaaS（Identity as a Service）とは、これらの認証プロトコルをクラウドサービスとして提供するプラットフォームです。自社でディレクトリサーバーや認証サーバーを構築・運用する代わりに、SaaS型のIDaaSを契約して認証基盤を委ねる形態が増えています。

主要3製品はそれぞれ次のような特徴があります。Okta^*4は独立系IDaaSとして、SSO・適応型MFA・ライフサイクル管理（プロビジョニング）・APIアクセス管理を提供します。マルチクラウド・マルチSaaS環境での中立的な連携基盤として評価されています。

Microsoft Entra ID（旧Azure Active Directory）^*5はMicrosoft 365・Azureとの親和性が高く、MFAによってID侵害リスクを99.22%低減できると公式に示しています。条件付きアクセスや機械学習を使ったID保護機能も備えています。

Auth0^*6はOkta傘下のIDaaSで、開発者向けのSDKとドキュメントが充実しています。B2Cアプリケーションへのソーシャルログインやカスタムルールの柔軟な実装が得意です。

内製vs外注——必要なスキルと工数で判断する

認証基盤の開発を内製するには、複数の専門知識を持つエンジニアが必要です。「ある程度書けるエンジニア」を複数名用意するだけでは、本番運用に耐えるセキュリティ実装には届きません。

認証基盤の実装に必要な専門スキル

認証基盤を内製で構築するためには、少なくとも次の知識が必要です。OAuth 2.0/OIDCのフロー（認可コードフロー・PKCE・クライアントクレデンシャルズ）の実装経験、SAMLアサーションの検証と署名処理、選定するIDaaS製品（Okta/Entra ID/Auth0）の設定・API操作の習熟、JWTの発行・検証・ローテーション設計、そして証明書管理やトークンストレージのセキュリティ設計です。

これらを一人のエンジニアがすべてカバーするのは容易ではありません。外注先がIDaaS認定資格（Okta Certified Consultant等）を持つ専任エンジニアを抱えているのに対し、内製では習得に数ヶ月から半年規模の学習期間を要することがあります。

外注が適切なケース・内製が適切なケース

外注が適切なのは、初回構築・既存システムへの統合・複数プロトコルの混在環境・スピードが優先されるケースです。反対に、内製が現実的なのは、すでにIDaaS設定の実績がある社内エンジニアがいる場合や、小規模のシングルサービス向けにAuth0のSDKを使うだけのケースに限られます。

外注すべき作業範囲——認証基盤開発の4フェーズ

認証基盤の開発を外注する際は、作業を「どこまで委託するか」を最初に明確にしておく必要があります。フェーズを分けて委託範囲を整理することで、見積もりの精度が上がり、後からのスコープ変更によるコスト増を防げます。

フェーズ1：要件定義とアーキテクチャ設計——使用プロトコルと連携システムの確定

最初のフェーズでは「どのプロトコルを使うか」「どのIDaaSを採用するか」「どのシステムと連携するか」を決定します。社内のシステム一覧、既存の認証方式（Active Directory、独自ログインページ等）、SSO対象のSaaSアプリをリストアップして委託先に提供できる状態にしておくことが大切です。

このフェーズを外注先任せにすると、自社の実態とかけ離れた設計になるリスクがあります。要件定義は発注者側が積極的に関与し、委託先はアーキテクチャ設計とプロトコル選定の技術判断を担う形が望ましいです。

フェーズ2：IDaaS設定・SSO/MFA実装——プロトコル別の実装精度が品質を左右する

フェーズ2では、選定したIDaaSの実際の設定作業と、各アプリケーションとの連携実装を行います。OIDCフロー（認可コードフロー＋PKCE）の実装、SAMLアサーションの署名検証設定、MFAポリシーの設定（SMS/TOTP/FIDO2等の認証器選択）が主な作業です。

特にSAMLは、IDプロバイダー（IdP）とサービスプロバイダー（SP）間のメタデータ交換と証明書管理に実務経験が必要です。設定ミスがあると認証が通らなくなり、本番後の修正は影響範囲が広くなります。

フェーズ3：既存システムとの連携・テスト——非互換の早期発見が工数を左右する

新しい認証基盤を既存システムに統合する際、最も工数が読みにくいのがレガシーシステムとの連携テストです。古いSPのSAML実装がIDaaSの仕様と合わない、あるいはOIDCに未対応のシステムがある場合、アダプター層の開発が必要になることがあります。

テスト工程では、正常系の認証フローだけでなく、トークン期限切れ・セッションタイムアウト・MFA失敗時のフォールバック動作を漏れなく確認します。不備があると本番後に認証不能状態が発生し、業務停止に直結します。

フェーズ4：運用・監視体制の引き渡し——「作って終わり」にしない体制設計

認証基盤は構築後も継続的な保守が必要です。証明書の更新期限管理、IDaaSのバージョンアップへの追従、不審なログイン試行の監視・アラート設定などが含まれます。委託先に保守フェーズも継続依頼するか、社内への知識移転（ドキュメント整備・ハンズオン）を含めた引き渡しをするかを、開発フェーズ開始前に決めておく必要があります。

委託先選定の3つの確認軸

認証基盤の外注先を選ぶ際は、一般的なシステム開発会社の評価基準ではなく、認証・ID管理に特化した確認軸で見ることが大切です。

主要IDaaSの導入実績と認定資格——技術力の客観的な指標として確認する

委託先が「認証基盤の開発ができる」と言っても、実績のないIDaaSで開発を始めると、トライアル費用と工数が見積もりに含まれていないケースがあります。Okta Certified Consultant・Microsoft認定資格（Identity and Access Administrator Associate等）・Auth0の技術パートナー認定といった公式資格は、実装経験の目安になります。

過去に担当したIDaaS製品・連携したシステム数・採用したプロトコル（SAML/OIDC/OAuth 2.0）を具体的に提示できる委託先を選ぶことを推奨します。

セキュリティ設計・ゼロトラスト対応の技術力——認証基盤固有のリスク管理能力

認証基盤は、不正アクセスの最初の関門になります。委託先がゼロトラストアーキテクチャ（ZTA）の概念を理解し、条件付きアクセスポリシーの設計・リスクベース認証の実装・特権アクセス管理（PAM）まで対応できるか確認します。

NIST SP 800-63-3（デジタルアイデンティティガイドライン・2017年6月発行。2025年8月にSP 800-63-4へ改訂・置き換え済み）^*7に基づくIAL（Identity Assurance Level）・AAL（Authenticator Assurance Level）の概念を踏まえた設計を提案できるかどうかも、技術水準の確認ポイントになります。

元請（プライムベンダー）としての一貫管理体制——複数サブベンダーの統合管理が品質に直結する

認証基盤の開発では、IDaaS設定・バックエンドAPI開発・フロントエンド実装・セキュリティテストと、複数の専門領域が絡みます。これらを複数の下請けベンダーに分散して発注すると、責任の境界が曖昧になり品質管理が難しくなります。

元請（プライムベンダー）として全フェーズを一貫して受け持ち、社内の複数専門エンジニアをコーディネートできる委託先が望ましいです。LASSICはIT事業部として、元請（プライムベンダー）の体制で対応しています。

外注前に整理すべき3つのリスク

認証基盤の外注は、準備不足のまま進めると後から修正が難しい問題が発生します。外注を決定する前に、次の3つのリスクを事前に確認しておく必要があります。

プロトコル選定ミスによる再実装コスト——OIDCとSAMLの混在環境での選択が鍵

既存システムがSAMLに対応しているか、OIDCのみ対応しているかによって、実装方針が大きく変わります。途中でプロトコルを切り替えると、IDaaS側の設定・アプリ側の認証コード・テストの全てをやり直す必要があり、工期と費用の両方に影響します。

要件定義フェーズで「連携対象システム一覧」と「各システムが対応するプロトコル」を委託先と一緒に確認することが、再実装コストを避ける第一の手段です。

既存システムとの非互換・テスト工数の肥大化——レガシー連携の現場でよく起きる問題

認証基盤を新しくしたとき、既存システム側が古い認証方式から切り替えられない場合があります。特にオンプレミスで稼働しているレガシーシステムは、SAML/OIDCに対応していないことがあり、Kerberos-to-OIDC変換やカスタムアダプターの開発が発生します。

このような非互換は、実際に連携テストを行うまで全貌が見えないことがあります。委託先に「レガシーシステムとの連携実績と対処法」を事前に確認し、見積もりにリスクバッファが含まれているかを確かめることが大切です。

ベンダーロックイン——IDaaS乗り換え時の移行コストを想定する

IDaaSはクラウドサービスであるため、契約終了・料金改定・機能廃止などのリスクを長期的に考える必要があります。OktaからEntra IDへ、またはその逆への移行には、SSO設定・プロビジョニングルール・MFAポリシーの全再設定と、連携済みアプリケーションのテストが必要です。

初回選定時から「将来乗り換えが必要になった場合の移行手順」を委託先と議論し、標準プロトコル（OIDC/SAML）準拠で設計することが乗り換えコストを下げる有効な方策です。独自APIや製品固有のカスタム機能に依存しすぎない設計方針を明記しておくことを推奨します。

まとめ——認証基盤外注の3つの判断軸

本稿では、認証基盤・IDaaS連携開発の外注について、プロトコルの役割から委託フェーズ・選定軸・リスクまでを整理しました。要点を3つに集約すると次のとおりです。

第一に、OAuth 2.0/OIDC/SAMLは役割が異なるプロトコルです。連携対象システムの対応状況を要件定義で確認してから委託先と仕様を固めることが、再実装コストを防ぎます。第二に、外注判断は「社内にIDaaS実装経験者がいるか」で決まります。初回構築・複数システム統合・エンタープライズ規模では外注の方が品質とスピードの両方で有利です。第三に、委託先選定では、IDaaS認定資格・元請（プライムベンダー）としての一貫管理体制・ベンダーロックイン対策の設計方針を確認することを推奨します。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：IETF「RFC 6749 The OAuth 2.0 Authorization Framework」（2012年10月）
2. *2　出典：OpenID Foundation「OpenID Connect Core 1.0 incorporating errata set 2」（2023年12月15日）
3. *3　出典：Auth0「SAMLとは」（2024年）
4. *4　出典：Okta「IDaaSとは」（2024年）
5. *5　出典：Microsoft「Microsoft Entra ID」（2024年）
6. *6　出典：Auth0「Identity and Access Management」（2024年）
7. *7　出典：NIST「NIST SP 800-63-3 Digital Identity Guidelines」（2017年6月）

Tweet