なぜ認証機能の開発は“誰も触りたがらない領域”なのか？ 開発負担軽減のための突破口：BtoCサービスが直面する認証のジレンマ

オンライン証券口座の大規模な乗っ取り事件を境にBtoCサービスは“認証の在り方”を再考せざるを得なくなった。高まる脅威と複雑化する認証、企業が抱える「開発しても報われない」ジレンマ──その行き詰まりをどう突破すればいいのか。

[PR／＠IT]

　企業のセキュリティ対策が新たな局面を迎えている。ビジネスでのデジタル化進展によって、サービスを利用する顧客のアカウントや決済情報を直接狙う攻撃が増加した。具体的には、ECサイトやオンライン証券、サブスクリプションサービスなどのBtoCサービスで、偽のWebサイトに誘導し、ログイン情報を窃取するフィッシングによって、顧客アカウントが侵害の危機にさらされている。

　この状況を世に広く知らしめたのが、2025年春に国内大手のオンライン証券サービスで起きたアカウント乗っ取り事件だ。「この事件では、利用する顧客のアカウントが乗っ取られ、不正な取引や出金が実行される被害が相次いで発生しました」と日立ソリューションズの松本拓也氏は説明する。

日立ソリューションズの松本拓也氏（サイバーセキュリティソリューション本部 認証セキュリティソリューション部 セキュリティスペシャリスト）

　「2025年4〜5月にかけて被害が急増したこの事案の原因は、金融機関を装ったフィッシングメールやマルウェアによってID／パスワードが窃取されたことでした。攻撃の手口自体は目新しいものではなく、何年も前から警戒されてきた『アカウント乗っ取り』の典型例です。この事例が世間に衝撃を与えたのは、その規模と対象の広さでした」

　被害の拡大を受け、各証券会社は緊急の対策を迫られた。2025年7月には金融庁が公表した「金融商品取引業者等向けの総合的な監督指針」の一部改正により、それまで任意設定としていた多要素認証（MFA：Multi-Factor Authentication）の必須化が求められるようになり、導入の動きが一斉に広まったのだ。しかしこの急ごしらえの対策は、セキュリティ強度を向上させた一方で新たな課題も浮き彫りにした。

　「セキュリティ意識の高いユーザーは以前からMFAを利用していましたが、必須化によってITリテラシーが高くない層や、手間を嫌うユーザーもMFAを使わざるを得なくなりました。その結果、ユーザビリティが洗練されていない認証方式を導入した一部のサービスで利便性が著しく低下し、顧客から『使いにくい』『操作が分からない』といった不満の声が上がるという事態が見られました」

　こうした独自実装による混乱は、セキュリティと利便性のバランスをどう取るかという、金融業界だけでなくBtoCサービス全般に通じる深刻な課題を改めて突き付けることとなった。

動いて当たり前、失敗は許されない　開発現場が抱える「認証機能のジレンマ」

　こうした状況の背景には、認証機能の実装はサービス開発において極めて重要であると同時に、企業にとって大きな負担になっているという厳しい現実がある。これは多くの企業が抱える「認証機能の開発におけるジレンマ」だと松本氏は指摘する。

　認証機能はサービスの安全性を高める上で必須の機能だが、技術の進展が早くキャッチアップや実装が難しい割に、実装したからといってサービスの売り上げが直接的に増えるわけではなく事業貢献という観点からは導入効果を説明しにくい。むしろ、セキュリティを強固にすればするほどユーザーに手間を強いることとなり、ユーザー体験（UX：User Experience）を損なう恐れがある。

　松本氏は開発現場におけるエンジニアの心理についても言及する。

　「認証機能は頑張って実装しても『動いて当たり前』と思われ、プラスの評価を受けにくい領域です。一方で、失敗してインシデントを起こせば厳しく責任を問われます。こうした“報われなさ”から、認証部分には関わりたくないという開発者も少なくありません。認証に詳しい専門人材が育たず、さらに開発やメンテナンスが難しくなるという負のスパイラルに陥っている企業もあります」

BtoCサービス企業の認証実装の救世主「Auth0」

　このようなジレンマから脱却し、自社サービスの強固なセキュリティを維持するための解決策となるのが、BtoCサービス向けのIDaaS（IDentity as a Service）である「Auth0」だ。

　Auth0を提供するOkta社はアイデンティティー管理の分野におけるリーダー企業であり、従来「フィッシング耐性」（Phishing Resistance）の重要性を提唱し続けてきた。Auth0はログイン機能やユーザー管理機能をクラウドサービスとして提供するものであり、開発者は自社アプリケーションにAuth0を“組み込む”だけで、高水準の認証機能を実装できる。

　Auth0の最大の特長は“開発者ファースト”の視点で作られている点だと松本氏は話す。

　「認証基盤として極めて高い信頼性を備えており、Okta社では99.99％^※1の可用性（SLA：Service Level Agreement）を保証しています。ミッションクリティカルなBtoCサービスでも安心してご利用いただけます」

※1 Okta「Auth0 Status Page」（2025年12月10日）

　多様な環境への適応が可能であり、数多くのプログラム言語およびフレームワークに対応したソフトウェア開発キット（SDK：Software Development Kit）が提供されている。開発者は複雑な認証プロトコルを深く理解していなくても、SDKを組み込むだけでセキュアな認証を実装できる。

　柔軟なカスタマイズが可能な点も魅力だ。認証プロセスに独自のロジック（JavaScriptコード）を組み込める。ログイン画面のデザインもHTML／CSSレベルで自在に編集可能で、自社ブランドの世界観を損なうことなくシームレスなUXを提供できる。

Auth0はログイン画面やユーザー登録画面を簡単にカスタマイズできる（提供：日立ソリューションズ）《クリックで拡大》

　松本氏は「Auth0は単なる認証サービスではなく、開発者を『認証機能の実装』という重荷から解放し、本来注力すべき提供サービスの価値創造に専念してもらうためのプラットフォームです」と話す。

高度な「パスキー」認証もワンクリックで実装可能

　オンライン証券の事例を受け、現在改めて重要視されているのがフィッシング耐性のある認証手段であり、その筆頭に挙げられるのが「パスキー」だ。パスキーとはFIDO2（Fast Identity Online 2）規格に基づき、端末の生体認証機能などを利用して公開鍵暗号方式で認証する仕組みだ。パスワードは使わず、サーバ側には認証結果の回答だけを送るため、フィッシングサイトで認証情報を盗み取られるリスクが仕組み上は存在しない。

　ただしパスキーを自社システムに一から実装するのは技術的にも高いスキルを要求される。FIDO2の仕様は複雑であり、WebブラウザやOSごとの挙動の違い（相性問題）も顕著だ。常にアップデートされる規格や端末仕様に追随し続けるためには、高度な専門知識を持ったエンジニアが必要となる。

　ここでAuth0の真価が発揮される。Auth0であれば、管理画面から設定するだけでパスキー認証を有効化できるのだ。

　「Auth0なら、ワンクリックでパスキーが使えるようになります。サーバとやりとりするデータ変換や端末ごとの差異の吸収といった面倒な処理は全てAuth0側が担います。サービス開発者は、Auth0が返す『認証成功』という結果を受け取るだけです」

　また、Auth0はログイン画面をAuth0のサーバでホスティングする形式（リダイレクト型）を基本とする。そのため、認証UI（ユーザーインタフェース）へのアップデートもAuth0側で自動実行される。

　「攻撃者は常に新しい手口を探しています。ログイン画面をAuth0側に任せるということは、そうした攻撃の矢面にAuth0が立つことを意味します。強固なセキュリティ対策が施された認証基盤を利用することで、脆弱（ぜいじゃく）性対応に追われることなく安全な状態を維持できます」（松本氏）

Auth0はパスキー認証をワンクリックで実装できる（提供：日立ソリューションズ）《クリックで拡大》

IDaaSへの乗り換えの障壁「パスワード移行」もスマートに解決

　Auth0が他のIDaaSと比較して際立っているもう一つの強みが、「他の認証基盤からの乗り換え（移行）の容易さ」だ。

　既存のオンプレミスや自社開発の認証システムからIDaaSに移行する際、最大の障壁となるのが「ユーザーのパスワードデータ」の扱いだ。通常、パスワードはハッシュ化（一方向の暗号化）してデータベースに保存されている。ハッシュ化されたデータから元のパスワードを復元できないため、単純にデータをIDaaSに移すだけではログインできない。

　そこで、IDaaSへの移行時は全ユーザーに電子メールなどで通知し、パスワードの再設定を依頼することになる。これはユーザーにとって面倒な作業であり、対応してくれないユーザーの離脱や、問い合わせ窓口へのクレーム殺到など、ビジネスリスクが高い。この「パスワードリセットの壁」が理由でIDaaSへの移行をためらう企業もある。

　Auth0はこの問題を「Automatic Migration」（自動移行）という機能で解決している。これは「遅延移行」（Lazy Migration）とも呼ばれる手法であり、仕組みは次の通りだ。まず管理者はユーザーのID（メールアドレスなど）だけをAuth0側にインポートする。そして、ユーザーが移行後に初めてログインした際、Auth0は入力されたパスワードを受け取ると、裏側でリアルタイムに旧認証システム（データベースやAPI）に照合する。パスワードが通れば旧システムでの認証を成功と見なし、このタイミングでユーザーが入力したパスワードをAuth0側にセキュアな形式でハッシュ化して保存する。

　「つまり、ユーザーから見れば今まで通りのID／パスワードでログインするだけで、裏側では自動的にAuth0への移行が完了できます。開発者がやることは、旧認証基盤への問い合わせロジックを書くことだけです。ハッシュアルゴリズムの違いなどもAuth0が吸収し、ユーザーにパスワード再設定の負担を強いることなく、スムーズな移行を実現します」

Auth0におけるパスワード移行の仕組み（提供：日立ソリューションズ）《クリックで拡大》

攻撃を自律的に防ぐ「Attack Protection」

　Auth0の利点は、実装や移行の容易さだけではない。運用フェーズでは、Okta社のグローバルな脅威インテリジェンスを活用した高度な防御機能「Attack Protection」が、次の機能によって攻撃を自動的に検知／防御する。これらの機能は設定画面でオンにするだけで利用できる。

• Bot Detection（Bot検知）：ログイン試行がスクリプトなどによるBotからのものである可能性が高い場合、自動的にCAPTCHA（画像認証）を表示して入力を求め、Botによる攻撃を阻止する
• Suspicious IP Throttling（不審なIPの制限）：同一のIPアドレスから大量のアクセスやログイン失敗を検知すると、そのIPからの通信を一時的にブロックし、システムへの負荷と不正侵入を防ぐ
• Breached Password Detection（漏えいパスワード検知）：ユーザーがログインに使用したパスワードが、過去に他サイトなどで漏えいしたデータと一致しないかどうかチェックする。一致した場合は、ユーザーに警告を発したり、パスワード変更を強制したりすることで、リスト型攻撃によるなりすましを防ぐ

　パスキーのような新しい技術への即応、UXを損なわないスムーズな移行、進化する脅威への自律的な防御──これらを自社で開発し、維持しようとすれば、膨大なコストとリソース、リスクを抱え込むことになる。松本氏は最後に、認証／セキュリティを外部の専門サービスに委ねることの重要性を次のように強調した。

　「IDaaSの導入を検討する際、利用料金を見て『コストが高い』と感じる経営者がいるかもしれません。しかし自前で実装した認証基盤に脆弱性が見つかり、セキュリティインシデントが発生した場合のことを考えてみてください。被害対応にかかる膨大な費用、サービス停止による機会損失、そして何よりも顧客からの信頼は一度失ったら取り戻すのが難しいでしょう。これらを天秤にかければ、認証のプロである外部サービスに任せて安全性を担保することは、極めて合理的でコストパフォーマンスの高い経営判断だと言えるでしょう」