会員認証は「作る」か「買う」か｜IDaaS/OSS/内製を実料金と規模で判断する

会員認証を自前で作るのか、IDaaS（認証のクラウドサービス）を買うのか。この判断を、「会員規模」と「その先の成長」を見ずに決めてしまうと、後で痛い目に遭います。小さく始めたつもりが、会員が増えるにつれて月額が想定の何倍にもなるか、逆に自前で抱えたセキュリティの保守が回らなくなる——どちらも、最初の判断を誤ったときに起きることです。この記事では、選択肢を IDaaS・OSS・内製の三つに整理し、それぞれで「何を実装せずに済ませられて、何を自分で背負うのか」という責任の切れ目、各社の実料金、規模別のコスト試算、そして判断のフレームまでを、具体で示します。「メリット・デメリット」の羅列では終わらせません。

選択肢は3つ、そしてコストのかかり方が根本的に違う

会員認証の作り方は、大きく三つに分かれます。IDaaS（Auth0・Amazon Cognito・Firebase・Okta など）を買う、OSS（Keycloak 等）を自社サーバーで運用する、そして内製でゼロから自作する。ここで見落としてはいけないのが、三者でお金のかかり方がまったく違うという点です。IDaaSは初期こそ安いものの、会員数（MAU：月間アクティブユーザー）に比例して月額が増えます。対してOSSや内製は、ライセンスは無料でも、インフラと運用の人件費という規模の影響を受けにくい固定的なコストが中心になります。つまり“今”の金額だけでなく、成長後のMAUまで見込んだ総額で比べる必要があるのです。

ただし、コストの形が違うのは結果にすぎません。その手前で効いてくるのが、認証という機能のどこまでを自分の責任範囲に置くかという切り分けです。ここを先に押さえると、料金表の読み方も変わってきます。

三つの方式を「責任分界」で捉える

認証は、ログイン画面という見た目の裏側で、いくつもの部品が動いています。ユーザーの資格情報を預かるユーザーストア、パスワードを安全に保つハッシュ処理、ログイン成功後に発行するトークン、その署名を検証するための鍵、外部IDと連携するフェデレーション、そして不正ログインを弾く防御機構。三つの方式の違いは、この部品群のどこまでを事業者が持ち、どこからをベンダーに預けるかという線引きにあります。

この表から読み取ってほしいのは、Keycloak のようなOSSが内製とIDaaSのちょうど中間に位置することです。OIDC・OAuth 2.0・SAML 2.0 の実装、Google や GitHub などの外部IDプロバイダとのアイデンティティ・ブローカリング、LDAP／Active Directory とのユーザーフェデレーション、TOTP や WebAuthn による多要素認証——こうした“作ると重い”部分は、製品として最初から揃っています。ライセンス費用もかかりません。その代わり、サーバーの用意、バージョンアップ、可用性の確保、負荷が増えたときのスケールは自社の仕事として残ります。「実装は買うが、運用は自分で持つ」のがOSSの立ち位置です。逆にIDaaSは運用ごとベンダーに預け、内製は実装も運用も丸ごと抱える。三方式は別物というより、責任をどこで切るかという連続した選択肢だと捉えると、判断がぶれません。

内製で「自前で背負う」もの——作る自由の代償

内製の魅力は、要件にぴったり合わせられる自由度です。しかしその自由と引き換えに、本来は事業の価値に直結しない“守りの実装”を、延々と自社で持ち続けることになります。何を背負うのか、具体的に見ていきます。

トークンの発行と検証、そして署名鍵のローテーション

OpenID Connect でログインを実装すると、認証後に id_token（本人性を表す）と access_token（権限を表す）を発行します。これらは多くの場合 JWT という形式で、RS256（RSA）や ES256（楕円曲線）といった方式で署名されます。受け取った側は署名を検証して改ざんされていないことを確かめますが、そのためには署名に使った公開鍵を配布する仕組みが要ります。標準では JWKS という公開鍵の一覧を公開し、鍵ごとに kid（鍵ID）を振って区別します。厄介なのは鍵のローテーションです。鍵は定期的に入れ替える必要があり、しかも古い鍵で署名した発行済みトークンが失効するまでは、新旧の鍵を両方公開し続ける必要があります。これを止めれば全ユーザーが弾かれ、雑にやれば検証が通らなくなる。地味ですが、事故が起きやすい運用の一つです。

セッションとリフレッシュトークンの管理

ログイン状態を保つには、短命な access_token が切れるたびに refresh_token で更新します。ここでリフレッシュトークンの盗用に備える設計——使うたびに新しいものへ入れ替えるローテーション、古いトークンが再利用されたら一連のセッションを無効化する再利用検知、ログアウトや退会時の失効——を、自分で用意しなければなりません。セッションをサーバー側で持つのか、トークンに状態を載せるのか、どこで失効を判定するのか。設計を一つ間違えると、ログアウトしたはずのユーザーが実は生きている、といった穴になります。

パスワードの保管とアカウントの名寄せ

パスワードは平文で持てません。bcrypt・scrypt・Argon2 のようなソルト付きのハッシュ関数で、計算コスト（ワークファクター）を調整しながら保存し、計算機の性能向上に合わせてその強度も見直し続けます。加えて、同じ人がメールで登録した後にLINEでもログインしたときに同一人物として束ねる名寄せ（アカウントリンク）、パスワードを忘れた人のための安全なリセット動線、これらすべてが自作対象です。どれも「認証があるサービスなら当然備わっているべき」ものでありながら、正しく作るには相応の専門性を要します。

攻撃への防御と、仕様変更への追随

総当たり攻撃（ブルートフォース）へのレート制限、漏えい済みパスワードの拒否、不審なログインの検知——こうした防御機構も、放っておいて備わるものではありません。さらに、外部ID連携を使うなら各社の仕様変更に追随し続ける負担が乗ります。SNSやプラットフォーム各社のログイン仕様は不定期に変わり、内容によっては“作り直し”に近い改修が突然発生します。対応するIDプロバイダを増やせば、その分だけ実装と保守が積み増しになります。新しい攻撃手口への対応も、監査ログの整備も、すべて自社が負う——これが内製のいちばん重い部分です。

認証は「作って終わり」ではなく「作り続ける」コミットメントです。自由度の対価として、守りの実装を永続的に保守する覚悟が要ります。

結論から言えば、内製はもう選ばれにくい

ここまでの“背負うもの”を並べると、結論はおのずと見えてきます。認証技術そのものが自社の競争力である一部のサービスを除けば、いまゼロから内製する理由はほとんどありません。 OAuth 2.0 や OpenID Connect を正しく実装し、トークンと鍵とセッションを安全に運用し、攻撃と仕様変更に追随し続ける——この一式は、多くの事業にとって価値を生む機能ではなく、落とすと事故になるだけの土台です。土台の建設と保守に自社の開発力を張り続けるより、実績のある実装を使い、人手を本業に回すほうが理にかなっています。実務では、「実装も運用も買う」IDaaSか、「実装は買って運用は持つ」OSSかの二択になるのが実情です。

IDaaSで「買える」もの——実装せずに手に入る機能

では、IDaaSを選ぶと具体的に何を実装せずに済むのか。ここが“買う”価値の中身です。単に「ログイン機能」を借りるのではなく、先ほど内製で背負っていた部品群が、設定だけで手に入ります。

主なものを挙げると、ソーシャル／LINEログイン連携（外部IDでの新規登録・ログイン）、多要素認証（MFA）（TOTP・SMS・生体）、パスキー／WebAuthn（フィッシングに強いパスワードレス）、企業向けの SAML／OIDC フェデレーション（取引先の Entra ID や Okta と接続する法人SSO）、ユーザーを預かるユーザーストア、総当たり攻撃を弾くブルートフォース対策、誰がいつログインしたかを残す監査ログ、そしてB2Bの組織対応（取引先ごとにテナントを分ける多テナント管理）。これらを自作せずに済むこと自体が、対価に見合う中身です。

「何が標準で、何が別対応か」は製品で割れる

ただし、同じ“買える”でも製品によって守備範囲が違います。とくに新しい認証方式ほど差が出ます。パスキー／WebAuthn を例にとると、対応の度合いははっきり分かれます。

たとえば Amazon Cognito はパスキーを Essentials ティア以上で標準サポートし、マネージドなログイン画面から登録・利用できます（無料の Lite ティアでは使えません）。Auth0 もパスキーや WebAuthn を標準で持ち、フィッシング耐性のあるログインを設定で有効化できます。一方 Firebase Authentication は、コアの管理機能としてのパスキー提供が手薄で、拡張機能や独自のトークン連携で補うのが現状です。つまり「パスキーに対応したい」という同じ要件でも、Cognito や Auth0 なら“買える”が、Firebase では“ひと手間かかる”。この対応差は、パスキーに限らず、法人SSOやB2B組織管理でも同じ構図で現れます。製品ごとの機能や向き不向きの詳細比較（BtoBアプリ視点）は 「Auth0 vs Firebase vs Cognito」 に譲り、この記事は“どれを選ぶか”の前段——“作るか買うか”に絞ります。パスキーそのものの仕組みは 「パスキー／パスワードレス」 に詳しくまとめています。

IDaaSの実料金——「買う」側の相場

“買う”側の相場を、各社の公開料金（執筆時点）で押さえます。共通するのは、MAU課金という考え方です。会員数が、そのまま料金の物差しになります。

規模で、コストはこう動く

「無料枠があるから安い」は、規模が小さいうちだけの話です。MAU課金は、会員が増えるほど効いてきます。Amazon Cognito Essentials（$0.015/MAU・無料10,000）を例に試算すると、次のようになります。

小規模なら無料〜数万円。しかし大規模になると、MAU課金が効いて年に数百万円規模まで伸びます。ここが、OSS自社運用に相対的な分があるかを分ける“逆転点”です。

逆に言えば、会員規模がまだ読めない立ち上げ期には、初期の軽いIDaaSが合理的だ、ということでもあります。「今は安いか」ではなく「成長曲線のどこで、どちらが得になるか」で見るのが、判断の勘所です。先ほどの責任分界と重ねると、MAU課金が重くなる規模では、「運用を自分で持つ」OSSの固定費が相対的に軽く見えてくる——コストの逆転は、責任の持ち方の見直しでもあります。

見落とすと高くつく——料金の“隠れた変数”

MAUの単価だけを見ていると、二つの変数を見落とします。一つは機能ティアです。たとえばリスク検知や脅威保護は上位ティア（Cognito なら Plus）に、パスキーやマネージドログインは中位ティア（Cognito なら Essentials）に入るため、「自社に必要な機能がどのティアか」を最初に確認しないと、無料枠や最下位ティアの単価だけで見積もり、あとで想定より高くつきます。法人SSO（SAML／OIDC 接続）も、下位プランでは接続できる企業数に上限が設けられていることがあり、取引先が増えるたびにプラン変更が要る、という形で効いてきます。

もう一つが課金モデルです。IDaaSやSalesforceの外部ユーザーライセンスには、「登録した会員数で課金するメンバー単位」と「ログインした回数で課金するログイン単位」の二つがあり、おおむね月4回を超えてログインするユーザーが多いならメンバー単位が割安、たまにしか来ないならログイン単位が有利、と分岐します。会員の“ログイン頻度”という、見落としやすい変数がコストを左右するのです。自社の利用実態がどちらに寄るかは、契約前に一度見積もっておく価値があります。

判断のフレーム——金額だけでは決まらない

コストは重要ですが、それだけで決めると足をすくわれます。次の軸で見ると、多くのケースで答えが出ます。

とりわけ移行可能性（パスワードハッシュをエクスポートできるか）だけは、契約前に必ず確認してください。ここを見ないと、後で乗り換えられず、コストが青天井になります。ロックインを避ける実務的な勘所は二点。ユーザー（ハッシュ済みパスワードを含む）をエクスポートできることと、OIDC／SAML などの標準に準拠していることです。標準準拠の製品どうしなら、アプリ側の改修を最小限に乗り換えられます。逆に独自方式へ深く寄りかかるほど、抜けられなくなります。データの保管場所を自社で握りたい、認証が事業の核である、超大規模でコストが逆転する——こうした条件がそろったときが、OSS自社運用や内製を選ぶ例外です。それ以外の多くの事業では、標準準拠でエクスポート可能なIDaaSを選び、成長後の総額を見ておく——この構えが無難です。

▶ 全体像は 「LINEログインとは？仕組み・できること・導入の判断」 にまとめています。