モノリシックな「Chatwork」から、認証基盤をどのように切り出していったか

2025年4月23日に株式会社overflow主催イベント「LayerX／kubellの実例から学ぶ プロダクトが大きくなっても壊れない 認証設計とは」での登壇資料です。
イベントページ：https://offers-jp.connpass.com/event/349513/
登壇者：株式会社kubell プロダクト開発ユニット 認証グループ 田中 浩一

Transcript

1. モノリシックな「Chatwork」から、認証基盤 をどのように切り出していったか 株式会社kubell（旧Chatwork株式会社） コミュニケーションプラットフォームディビジョン プロダクトユニット 認証グループ 田中 浩一 2025.04.23 #Offers_DeepDive 「LayerX／kubellの実例から学ぶ プロダクトが大きくなっても壊れない認証設計とは」 LT資料
2. Introduction • 現在、「Chatwork」の認証機能部位は、Auth0というIDaaSによって担われています。Auth0を中核とした認証基盤 は、「Chatwork」本体から、論理的、かつ物理的に切り離された構成となっています。 • しかし、こうしたアーキテクチャーとなったのは2023年のことです。それまでの認証機能部位は、「Chatwork」本体 とモノリシックに一体的でした。年単位の大改修を経て、現在のアーキテクチャーへの移行が完了しました。 • 本発表では下記の様な内容についてお話します。: ◦ なぜそのような大改修を経ての認証基盤の切り出しを実施することとしたのか、そのビジネス的背景や狙い ◦ IDaaS導入や、伴う改修はどのように進められたのか、その過程でどのような問題が生じたか ◦ 結果として、現在の認証基盤のアーキテクチャーはどのようなものとなっているのか 2
3. 目次 CONTENTS 01 | Chatwork株式会社から株式会社kubellへ 02 | IDaaS（Auth0）導入と移行開発の実 際 03 | 認証基盤の概念的整理（BPaaS戦略の 下での、認証基盤の立ち位置）
4. 01 | Chatwork株式会社から 株式会社kubellへ
5. 2024年7月1日よりChatwork株式会社は、株式会社kubell（読み：クベル）に社名変更しました。 株式会社kubellは、誰もが使いやすく、社外のユーザーとも簡単につながることができる 日本最大級のビジネスチャット「Chatwork」を運営しています。 また、チャット経由で会計、労務、総務など様々なバックオフィス業務をアウトソースできる 「Chatwork アシスタント」などのBPaaSサービスを幅広く展開。 ビジネスチャットの会社から、BPaaSで「働く」を変えるプラットフォームを提供する会社へ事業領域を拡張します。
6. なぜ社名変更したのか？ 6 • 「Chatwork」事業に加えて、新事業「BPaaS」を始めたことが一つの大きな理由 引用: 株式会社kubell "2024年12月期 通期決算説明資料", 2025年2月14日
7. 「BPaaS」事業とは何か？ 7 • 多様なSaaSが利用できていても、多数のSaaSを使いこなしつつの業務プロセス構築は難易度が高い • それを解決するために、業務プロセスを丸ごと巻き取るBPaaSが有効 引用: 株式会社kubell "2024年12月期 通期決算説明資料", 2025年2月14日
8. 「BPaaS」のイメージ 8 1. お客様から、「Chatwork」や「BPaaS窓口」を通して、”仕事”を依頼、つまり発注いただく 2. 受注側（つまりkubellのBPaaS組織）は、業務プロセスを進行させて、終わったら完了報告（納品）をする 引用: 株式会社kubell "2024年12月期 通期決算説明資料", 2025年2月14日
9. 「Chatwork」以外の最初のプロダクト、「フロントデスク」とは？ • 「BPaaS窓口」とは、依頼（アウトソーシング）したい業務を、「案件」としてまるごと発注（契約&決済）できるシ ステム的な仕組み • 「フロントデスク」とは、その内の顧客が利用する画面部位についてのプロダクト 9 引用: 平本 康裕 “SaaSの次なる潮流BPaaS ゼロイチの事業づくりと伴走するプロダク ト開発の裏側”, Developer Summit 2025 登壇資料, 2025年2月14日
10. 「BPaaS」事業の、認証グループによる受け止め 10 • 認証グループは、「BPaaS」が展開されるということは、「Chatwork」以外のプロダクトが登場し、それらのプロダ クトへ認証提供していくことを意味している、という点を受け止め Chatwork フロントデスク プロダクトY アカウント 認証基盤 プロダクトZ Chatwork アカウント
11. 02 | IDaaS（Auth0）導入と移行開発の実際
12. 前提知識 • 「IDaaS（”IDentity as a Service”）」とは？: ◦ IDやパスワードを一元集中管理し、ログイン画面を含む認証機能を提供するSaaS ◦ IAM（”Identity and Access Management”）機能を提供するSaaS（”IAM as a Service”と言ってもよい） • 「Auth0」とは？: ◦ Okta社によって運営されるIDaaSの一つ（現在は「Okta CIC（”Customer Identity Cloud”）」と称されてい る） • 他にIDaaSにはどんなものがあるか？: ◦ Amazon Cognito ◦ Microsoft Entra ID / Entra External ID ◦ Google Cloud Identity Platform ◦ GMO トラスト・ログイン • 「CIAM（”Customer Identity and Access Management”）」とは？: ◦ 企業内の従業員のID管理ではなく、サービスを利用する顧客のID管理を特に意図したIAM機能 ▪ 従業員のID管理を意図したIAM機能を「EIAM（”Enterprise Identity and Access Management”）」と称 することも ◦ IDaaSによって、CIAM向け、EIAM向けといった違いがある 12
13. IDaaSを導入するに至った背景 13 引用: 山下 賢治 “Okta CIC Actionを活用した独自の認証関連機能の移行方法、およびログやメトリクスの 監視手法について実例紹介 ”, Okta Japan主催 Okta CIC Meetup 登壇資料, 2024年7月11日 Okta CIC = Auth0の新名称 738万以上 (2024年12月末時点)
14. IDaaS選定時の比較項目 • パフォーマンス: ◦ 「Chatwork」のMAU推移予測に対して、十分カバーできるパフォーマンスプランを提供している事 • 費用体系: ◦ CIAM目的であり、MAUベースの料金体系である事 • 不正ログイン対策: ◦ 不正ログイン対策機能に関して、IDaaS自身が継続的に拡充を行なっている事 • その他、各機能のFit/Gap: ◦ CIAM向けであること ◦ SAML認証, Social Login, CAPTCHA, MFA, ...といった機能が直接サポートされている、または実現可能である事 ◦ URLに独自ドメインが使用できる事, ログイン画面のカスタマイズができること ◦ ネイティブモバイルアプリ向けにもログイン画面を提供できる事 14
15. Auth0を前提とした認証機能部位リプレース開発計画、その１ • 基本的な開発ミッション: ◦ “「Chatwork」の認証機能部位を、Auth0にリプレースする” • リプレース開発の技術的要点: ◦ モノリシックに作り込まれている「Chatwork」の認証機能部位を、Auth0というOIDC認証サーバー （OpenID Provider）と、「Chatwork」というOIDCクライアント（Relying Party）との構成に分離する こと ▪ Auth0は、そもそもOIDC認証サーバー（OpenID Provider）である ▪ 「Chatwork」を、OIDCクライアント（Relying Party）として振る舞うよう改修する 15
16. Auth0を前提とした認証機能部位リプレース開発計画、その２ 16 • 移行開発進め方のねらい: ◦ 「Chatwork」の認証機能が、OIDC認証サーバーとOIDCクラアイントに分離されれば、自ずと、「Chatwork」 以外のOIDCクライアントへの認証提供も可能となる Chatwork Chatwork (OIDCクライアント) Auth0 (OIDC認証サーバー) アカウント アカウント Chatwork (OIDCクライアント) フロントデスク (OIDCクライアント) プロダクトY (OIDCクライアント) アカウント 認証基盤 (OIDC認証サーバー)
17. 移行開発、一段階具体化しての進め方 1. 「Chatwork」の既存の認証関連機能（「認証要素」）にはどんなものがあるのか洗い出して列挙する。 2. どの機能をAuth0へ任せて、どの機能を「Chatwork」側に残すべきか？一つ一つ見極めていく。 17
18. 「認証要素」を洗い出す 18 パスワード認証 SAML認証 Google認証 Apple認証 2段階認証 休眠アカウント メール認証 アカウント停止 組織間移行中 アカウントロック Chatwork www.chatwork.com
19. 「認証要素」を移行計画に応じて分類する A. そのままAuth0提供機能を利用する ✓ （将来の）認証基盤として、「Chatwork」以外のプロダクトへも提供したいもの ✓ かつ、Auth0にそのまま置き換え可能な機能が有る B. Auth0 Actionsを利用して、カスタム実装する ✓ （将来の）認証基盤として、「Chatwork」以外のプロダクトへも提供したいもの ✓ しかし、Auth0にそのまま置き換え可能な機能が無い C. 「Chatwork」に残す ✓ 「Chatwork」というプロダクト固有の機能だと判断されるもの 19
20. 「認証要素」をそれぞれ移行開発する • パスワード認証, SAML認証, Google認証, Apple認証, アカウントロック, ... ✓ 基本的な認証機能は、Auth0提供の当該機能をそのまま利用 ⇒ Auth0へ移行するので、既存コードは破棄する • 2段階認証, 休眠アカウント・メール認証, ... ✓ Auth0 Actionsを利用してカスタム実装しつつ、OIDC認証サーバー側へ移行 ⇒ コードを切り出して、Auth0 Actionsと連携して動くものに改変する • アカウント停止, 組織間移行中, ... ✓ 「Chatwork」側の責務として残す ⇒ OIDCクライアントとして、Callbackエンドポイントにて実現されるように、コードを再編成する 20
21. 「認証要素」 As-Is（再掲） 21 パスワード認証 SAML認証 Google認証 Apple認証 2段階認証 休眠アカウント メール認証 アカウント停止 組織間移行中 アカウントロック Chatwork www.chatwork.com
22. 「認証要素」 To-Be 22 OIDC認証サーバー Auth0 Actions カスタム実装 休眠アカウント メール認証 組織間移行中 アカウント停止 www.chatwork.com Chatwork (OIDCクライアント) auth.chatwork.com
23. ・・・と、さらっと言ってますが、 • 実際の移行開発は、 ◦ Auth0提供の相当機能をそのまま利用する機能部位については、、、 ⇒ 既存コードは破棄！ ◦ Auth0 Actionsを利用してカスタム実装しつつ、OIDC認証サーバー側へ移行する機能部位については、、、 ⇒ コードを切り出して、Auth0 Actionsと連携して動くものに改変 ◦ 「Chatwork」側matterとして残す機能部位については、、、 ⇒ OIDCクライアントとして、Callbackエンドポイントにて実現されるように、クラス類を再編成する • つまりは、地道に続くリライティング（再実装）・・・ ◦ 年単位の開発期間の半分は既存コードの再編成に費やしていた 23
24. 03 | 認証基盤の概念的整理 （BPaaS戦略の下での、認証基盤の立ち位 置）
25. 振り返り 25 1. kubellは、「Chatwork」事業に加えて、「BPaaS」事業に取り組み始めた 2. システム的には、「Chatwork」以外に複数プロダクト展開されることを意味する 3. 複数プロダクトへ認証提供するための、認証基盤が必要 4. まずは既存の「Chatwork」の認証機能部位をAuth0前提でリプレースする、というゴール設定で移行開発 Chatwork Chatwork (OIDCクライアント) Auth0 (OIDC認証サーバー) アカウント アカウント Chatwork (OIDCクライアント) フロントデスク (OIDCクライアント) プロダクトY (OIDCクライアント) アカウント 認証基盤 (OIDC認証サーバー)
26. 認証要素、何を認証基盤へ持っていき、何を「Chatwork」に残したか • 認証基盤へ持っていった認証要素: ✓ 認証基盤として、「Chatwork」以外の全てのプロダクトへ共通して提供したいもの ➢ 結論として、純粋に認証のみを、認証基盤の責務とした • 「Chatwork」に残した認証要素: ✓ 「Chatwork」というプロダクト固有の機能だと判断されるもの ➢ プロダクト固有の問題は、プロダクト固有の認可の問題であると、えいっと割り切り 26
27. なぜ「認可」は扱わないか？ • 根本原理の認識: ◦ 「認可」のモデルとはビジネスモデルそのものである ◦ これを無理に統合することはしない • kubellの複数プロダクト展開における状況: ◦ プロダクトによって、そもそも「契約」が異なる ⇒ Principalを束ねる単位の概念がプロダクトごとに異なる ▪ ビジネスモデル的要請から、各プロダクトの契約は、セールスプロセス上基本的には独立している • 「Chatwork」は、全社導入だったり、部門導入だったり、まちまち • 「フロントデスク」は部門導入前提 • 「プロダクトY」は全社導入前提 ◦ プロダクトによって、権限管理したい対象が異なる ⇒ Resourceの概念がプロダクトごとに異なる ▪ 「Chatwork」は、チャットルームやチーム ▪ 「フロントデスク」は、「案件」 ▪ 「プロダクトY」は、ある種のグループ（「Chatwork」のチャットルームやチームとはまた別のもの） • 結論: ◦ もっぱら、アカウントの本人認証のみを認証基盤の責務とする ▪ 個人としてのPrincipal概念（だけ）を統合、共通化する 27
28. 認証基盤への三つのミニマム要求 28 • 認証基盤に対する要求纏めに取り掛かるにおいて、ビジネスモデルやプロダクト戦略が変化しても、なにせ複数プロダ クト展開することに違いはない点に注目 • 複数プロダクトを展開する事から、下に示す様な三つのミニマム要求が発せられる、と整理される（た） • これを実現するものとして認証基盤を計画する（した） 顧客ベース アカウント ミニマム要求 プロダクト シングル・サイン・ オン 複数プロダクトを シームレスに利用で きる 再度の本人確認（メ アド確認）不要 あるプロダクトに於 いて一度アカウント 登録したら、他のプ ロダクトを利用する 時再度登録しなくて よい 共通ID アカウントの属性や アクティビティを、 プロダクト横断的に 紐づけられる Chatwork フロントデスク プロダクトY プロダクトZ
29. 認証基盤の責務の範囲についての、今現在の結論 • 責務の上限: ◦ アカウントの本人認証まで ◦ 「認可」は、各プロダクトに任せて、扱わない • 責務の下限: ◦ 「三つのミニマム要求」 ✓ 再度の本人確認（メアド確認）不要 ✓ シングル・サイン・オン ✓ 共通ID 29
30. 付録
31. 参考資料 • 田中 浩一 “ログイン機能をAuth0に移行した話（一人のシニア開発者の目線から）”, kubell Creator’s Note, 2023年 12月13日 ◦ https://creators-note.chatwork.com/entry/2023/12/13/000000 ◦ 本発表者による社員ブログ • 山下 賢治 “Okta CIC Actionを活用した独自の認証関連機能の移行方法、およびログやメトリクスの監視手法について 実例紹介”, Okta Japan主催 Okta CIC Meetup 登壇資料, 2024年7月11日 ◦ https://speakerdeck.com/kubell_hr/240711-yamashita ◦ 認証グループメンバーによる、Auth0カスタマー対象のMeetup登壇資料 • 平本 康裕 “SaaSの次なる潮流BPaaS ゼロイチの事業づくりと伴走するプロダクト開発の裏側”, Developers Summit 2025 登壇資料, 2025年2月14日 ◦ https://speakerdeck.com/kubell_hr/devsumi2015-hiramoto ◦ BPaaS事業VPoEによるデブサミ登壇資料 • 株式会社kubell "2024年12月期 通期決算説明資料", 2025年2月14日 ◦ https://contents.xj-storage.jp/xcontents/AS04681/13ad73fa/b7cd/4fcd/a681/a6999481ddb8/20250 214193459598s.pdf 31
32. 32 kubellでは ミッションに共感し、ともに実現していく仲間を募集しています （キャリア登録やニュースレター登録も受け付けています！） kubell エンジニア採用 https://www.kubell.com/recruit /engineer/ エンジニアを絶賛募集中です！
33. 33 もっと知りたい方はこちら “kubellグループの日々をとどける”メディア kubell days “kubellのエンジニアブログ” Creater's note 情報がぎゅっと詰まった 「Chatwork」エンジニア組織 紹介資料 https://days.kubell.com/ https://speakerdeck.com/kubell_ hr/chatwork-engineer https://creators-note.chatw ork.com/
34. 働くをもっと楽しく、創造的に 34