Finatextと認証認可〜直面していた4つの問題〜

Finatextグループは、次世代の金融インフラの提供を通して、組み込み型金融を実現するフィンテックを世に提供することに取り組む企業グループです。「金融を”サービス”として再発明する」というミッションのもと、フィンテックソリューション、データ＆AIソリューション、データ、証券、保険、貸金など、複数の事業領域で多数のプロダクトを提供しています。

証券・保険・貸金の3事業を含む金融インフラストラクチャ領域では、事業ごとにマルチテナントかつマルチプロダクトを提供可能なSaaSの開発・運用をしています。具体的には、これまで扱いづらいとされてきた金融のシステムやレガシーな業務フローをSaaSのAPIとして提供することで、より簡単で高速な金融サービスの展開を実現しています。

Finatextでは、各プロダクトの開発チームが技術選定から運用までを一貫して担当する体制を取っています。プラットフォームチームが共通のツールやガードレールを提供していますが、各チームは独立した環境で開発を進められ、インフラやAWSアカウントの権限管理も自律的に行っています。



このような体制は柔軟な開発を可能にする一方で、認証認可の実装において課題が見えてきました。例えば、あるプロダクトで「OAuth 2.0準拠のAuthorization codeフローを提供したい」と検討した際、いくつかの課題が目に入るようになってきました。

まず課題となったのは、再利用の難しさです。先行事例があっても個別要件に特化した実装のため、新規導入時には再度リスク検証から始める必要があります。また、開発チーム間のコミュニケーションコストが高いため、共通化への取り組みも進みにくい状況でした。さらに、既存実装の機能が不足している場合、安易なコードの複製と拡張が行われ、車輪の再発明やナレッジのサイロ化を引き起こしていました。

また、当社の開発スタイルも課題でした。私たちは一定期間で一気に開発しリリースするというスタイルを取っており、各プロダクトの要件に応じた個別最適化が優先される傾向にありました。金融ドメイン固有の機能については汎用化や共通化の重要性が認識されやすい一方で、認証認可は優先度が低く扱われ、技術的負債が蓄積されやすい状況でした。

さらに問題だったのが、標準化された認証認可の技術や仕様を個別要件に合わせて拡張していく過程で、セキュリティの妥当性に関する議論が十分になされなくなっていたことです。プロダクト固有の実装と認証認可の境界があいまいになり、結果として専門性の希薄化が進むという課題が生まれていました。

当社は金融に関わる情報を扱っており、アジリティとセキュリティの両立が求められる中で、認証認可の品質は非常に重要です。このまま認証認可領域が負債化してしまうと、会社としてのアジリティやセキュリティを損なう可能性があり、業界からの信用にも関わる問題となりかねません。

そこで私たちは、これらの課題に対して組織的なアプローチを行っていきました。

認証認可領域への組織的アプローチ

Finatextは認証認可の課題に対し、2023年12月にCTO主導でイネーブリングチームを設立しました。なお、このチームは認証認可に限らず、同じような課題感を持つ複数の領域で組成されました。

イネーブリングチームは社内の課題解決にとどまらず、業界における競争優位性の確立を目指しています。各事業領域から1〜2名のメンバーが参加し、専門的なナレッジを各領域に還元する役割を担います。また、個別の要件や締め切りに縛られない活動スタイルにより、技術的なアーキテクチャを深く追求できます。

こういったイネーブリングチームの考え方は書籍「チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計」の考え方を参考にしました。理由は、特定事業領域だけで取り組むとナレッジが局所化してしまい、再利用が進まないこと。また、既存の組織横断プラットフォームチームでは個別要件の理解に時間がかかりすぎるという課題があるためです。

イネーブリングチームでは、新認証認可基盤を開発し、既存の仕組みを刷新するという決断を下しました。新基盤に求められるのは、開発コストの削減とセキュリティの両立です。さらに、マルチテナント・マルチプロダクトの環境をサポートしながら、各事業領域で運用可能な適度な複雑さを実現する必要がありました。つまり、過度に複雑な設計は運用の障壁となり、逆に単純すぎる設計では機能が不足してしまうという、難しいバランスが求められました。

また、メンバーは専門的な知見を各事業領域に持ち帰って共有する一方で、現場で発生する課題をチームに持ち寄って議論します。このような双方向の情報流通により、組織全体の技術力向上を実現することを目指しました。

新しい認証認可基盤の開発においては、技術的なアーキテクチャの考え方を決めてそれを前提に開発することが決まりました。まず1つは、各要件を徹底的に汎用化して実装することです。もちろん、単に機能を実装するだけでなく、開発者が理解しやすく、かつセキュリティを担保できるガードレールを備えた設計を目指しました。

もう1つは、すでに存在するプロダクトでも十分に活用できるように最大公約数的な機能群を再設計して実現することです。各領域、各プロダクトで求められる要件は大きく異なりますが、それらの共通部分を見出し、簡略化して再設計する必要がありました。私たちは、この困難な課題に対して、まず各領域の知見を収集することから始めたのです。

新認証認可基盤の設計

新認証認可基盤の設計にあたり、まず技術選定の条件を整理しました。最も重要なのは、標準的な認証認可プロトコル（OAuth/OIDC）への対応です。

次に、多様な認証方式への対応が求められました。私たちのサービスにはさまざまな利用シーンがあります。toC向けではID/パスワード認証、マジックリンク、WebAuthnなどさまざまな認証方式が必要です。toB向けでは管理画面へのOIDCやSAML連携、MFA対応が求められます。さらにM2Mではサーバー間連携のための認証も必要でした。

また、マルチテナント環境のため、テナントごとのユーザー管理と権限管理が必要でした。また、将来的にはFinancial-grade API（FAPI）への対応も視野に入れる必要がありました。

そして金融機関向け基幹システムとして、高度なセキュリティと信頼性の確保は不可欠でした。個人情報を扱うため、導入企業に対して高い水準の信頼性を担保する必要があったのです。

これらの課題を解決するうえで、私たちは開発・運用コストの最適化を重視しました。本来の事業ドメインである金融サービスに注力するため、認証認可基盤についてはSaaSの活用を検討することにしたのです。

具体的には、海外の大手IDaaS（A社）とAmazon Cognitoの2つを比較検討しました。A社の製品は認証やユーザー管理を包括的に提供し、豊富な標準機能とライブラリ、高いカスタマイズ性を備えていました。一方、Amazon Cognitoは標準機能に制限はあるものの、ユーザープールを分割することでマルチテナントに対応できることがわかりました。

技術要件は両者とも満たせる見込みでしたが、最終的な判断ではコストが決め手となりました。A社は機能面で優れていましたが、金融機関向けに必要な上位プランの契約費用やMAUベースの課金体系が、私たちのビジネスモデルに合いませんでした。また、オールインワンのソリューションが故のベンダーロックインも懸念材料でした。

そこで私たちはAmazon Cognitoを採用することに決めましたが、いくつかの技術的な課題がありました。標準で提供されるHosted UIは日本語対応が難しかったこと（最新のアップデートでは日本語に対応）。また、独自UIを採用すると認証・認可の一部機能を自前で実装する必要があったのです。SaaS活用によるコスト削減という当初の目的を考えると、OAuth/OIDCのような重要な機能の独自実装は避けたいところでした。

この課題を解決するため、私たちは認証処理とOAuth/OIDCフローを分離するアーキテクチャを考案しました。具体的には、認証処理をAmazon Cognitoに任せ、OAuth/OIDCの処理は別製品で扱う構成です。

OAuth/OIDCの実装について、私たちは2つの選択肢を検討しました。1つは国内SaaSのB社の製品で、APIを通じて簡単にOAuth/OIDC準拠のインターフェースを提供でき、RFCやFAPI 2.0への追従も早いという特徴がありました。もう1つはOry Hydraで、Goで書かれたOpenID Connect準拠のOSSです。クラウドネイティブ環境との親和性が高いものでした。

両者ともPoCで要件を満たすことを確認しましたが、最終的にOry Hydraを採用しました。その理由は主に2つあります。まず、どちらも自社での開発やインフラ運用は必要ですが、Ory HydraはOSSのため利用料金が不要という点です。次に、SaaS特有のセキュリティ審査の課題があります。金融機関のお客様から求められる厳格なセキュリティチェックが、利用するSaaS全てに要求されるため、新たなSaaSの採用は運用負荷の増加につながってしまいます。

ただし、将来的に起こり得るFAPIなど最新RFC対応の必要性も考慮し、B社の製品は必要に応じてオプションで導入できる余地を残すことにしました。このように、現在の要件と将来の拡張性を両立させる設計を選択したのです。

このシステムは、ALBを通じてクライアント（Relying Party）からのリクエストを受け付け、認証系のリクエストを自社開発APIで処理する構成となっています。認証基盤としてテナントごとにAmazon Cognitoを配置し、OAuth/OIDC系のリクエストはOry Hydraで処理を行います。
大きな特徴としては、Amazon Cognitoを直接利用せず、自社開発サーバーでラップして利用することで柔軟な拡張性を確保しています。これにより、メールアドレスの使用状況の隠蔽やクライアント単位での認証方法の切り替え、ログイン履歴の管理など、要件に応じた細かなカスタマイズが可能となっています。

テナント管理については、Amazon Cognitoにその機能がないため自社で構築しました。また基幹システムでは契約情報一覧のCSV一括出力などの機能が必要となりますが、Amazon CognitoのAPIにはレートリミットがあり性能面での制約があります。サインアップやアップデートなどの操作は必ず自社APIを経由する設計としているため、その時点での最新状態をキャッシュとして保持するようにしました。これにより、リアルタイムでの情報取得が必要な場合はAmazon Cognitoから直接データを取得。大量データ処理が必要な場合はキャッシュしたDBから取得する柔軟な運用を実現しています。

認証フローについては、ユーザーがログインボタンを押下すると、クライアントはHydraへリダイレクトし、ログインチャレンジというワンタイムトークンが発行されます。認証サーバーでログインページを表示し、ユーザーの入力後にAmazon Cognitoで認証処理を行います。認証成功後、Hydraが認可コードを発行し、最終的にアクセストークンがクライアントに返される流れとなっています。

M2M認証については、OAuthのクライアントクレデンシャルズフローを採用し、Hydraによるスコープ管理を実現しています。また、個社固有の要件に対応するため、認証前後でWebhookを呼び出す仕組みを実装しています。

また、ユーザー識別子については、Amazon Cognitoの自動採番に依存せず、独自の採番方式を実装することで、グローバルでのユニーク性を担保し、将来的なデータ移行にも対応可能な設計としています。

アーキテクチャ面では、ヘキサゴナルアーキテクチャを採用し、将来的な認証基盤の変更にも柔軟に対応できる設計としています。これにより、FAPIへの対応など、将来的な要件変更にも適応可能な構成を実現しています。

新認証認可基盤のプロダクト展開

この新しい認証認可基盤のプロダクト展開について、まず保険事業からお話しします。ここでの最大の課題は、マルチテナントSaaSにおける可視性の制御でした。別のテナントの情報が見えてしまうような事態は重大な事故につながるため、より一層のセキュリティ強化が必要でした。

そこで私たちは、アクセストークンにtenant_idをカスタムクレームとして設定する方法を採用しました。これにより、アクセストークンを持つユーザーがどのテナントで認証されたかを追跡できるようになりました。具体的には、クライアントからBFFへ、そしてSaaS Coreへとアクセストークンを引き回すことで、すべてのレイヤーでテナントに応じた可視性制御を実現し、セキュリティレベルを向上させることができました。

続いて証券事業への展開では、異なるアプローチを取る必要がありました。既存システムではAmazon Cognitoをテナントごとに作成し、独自実装のAuthorization code flowで認証認可を実現していたためです。このような状況で、新基盤への移行を一気に行うことは現実的ではありませんでした。

そこで私たちは、SaaS上で新規に認証認可基盤を導入しつつ、Amazon CognitoとOry Hydraの両方を許容できるように拡張する方針としました。個別要件を汎用化して実装し、それを順次導入していく形で移行を進めたのです。たしかにアクセストークンの解釈などで複雑性は増しましたが、一斉マイグレーションのリスクを避けるためには必要な選択でした。

最終的には、Amazon Cognitoへのダイレクトアクセスを完全になくし、新基盤への統合を目指しています。これにより、これまでAmazon Cognitoの制約のために実現できなかった機能の提供が可能になり、よりシンプルで安定したシステムの実現が見込めるようになりました。

成果と今後の展望

まだ完了していない部分もあるものの、新しい認証認可基盤の導入では具体的な成果が表れています。

最も顕著な成果は、基盤に実装された機能の再利用が活発に検討されるようになったことです。ある領域で実現したユースケースが他の領域に知られることで、新機能の追加実装時に既存のナレッジを活用できるようになりました。イネーブリングチームのメンバーが中心となって各事業領域のエンジニアに知見を広めることで、再利用性の高い状況が生まれています。

開発面以外でも、実装と導入実績の存在が組織内に浸透することで、各事業領域のメンバーの認識も変化してきました。プロダクト開発において、まず開発に着手するのではなく、既存の基盤の活用を検討するようになり、より直接的な価値への貢献が見込める状況が生まれています。

今後の展望については、以下の3つの方向性を考えています。

第一に、新認証認可基盤の社内展開の拡大です。現在は段階的な展開を進めている状況ですが、個別要件に対応した実装を汎用化するには依然として課題があり、イネーブリングチームを中心とした継続的な検討が必要です。

第二に、競争優位性に直結する機能開発の推進です。パスキーやID連携の拡充、FAPI対応など、より高度な認証認可機能の実現に取り組んでいく予定です。

第三に、社内サポートとナレッジの浸透です。各領域全体にナレッジを展開し、イネーブリングチームの最小限のサポートだけで新基盤を導入できる状態を目指しています。

ここまでお話しした内容をまとめますと、Finatextは認証認可領域における課題に対し、2つのアプローチで取り組みました。まず、イネーブリングチームによる組織的アプローチです。認証認可基盤に責任を持つ専門チームを設置することで、技術的な妥協のないアーキテクチャ選定が可能になりました。 そして、Amazon CognitoとOry Hydraを組み合わせた技術的アプローチです。コストと運用効率を考慮しつつ、マルチテナント・マルチプロダクト環境における様々なユースケースに対応できる基盤を実現することができました。

これらの取り組みにより、将来を見据えた認証認可基盤の構築が実現できたと考えています。