田中浩一（@Tanaka9230）と申します。この記事はChatwork Advent Calendar 2023 13日目の記事です。
◇
去る、2023年1月25日、2023年6月30日、下記のようなアナウンスをさせていただきました。
2023/01/25 - 【重要】 ログイン画面リニューアルに伴う、メールアドレス・パスワード確認のお願い
2023/06/30 - モバイルアプリのログイン画面リニューアルのお知らせ
このリニューアルにて、Chatworkのログイン画面を含む認証系が、Auth0というIDaaSに置き換えられました。
Auth0とは？
一般にIDaaSと称される、「IDやパスワードを一元管理し、認証機能を提供するSaaS」の一つです。
Auth0を導入する事で、ログイン画面、その他認証に関わる下記のような機能を、Auth0にお任せできるようになりました。
- メールアドレス、パスワードの管理
- SAML認証、Google/Apple ID認証のサポート
- CAPTCHAのサポート
- 多要素認証のサポート
- Bot検知、不審IP検知、その他の攻撃対策
なぜIDaaS（Auth0）を導入することとしたのか？
Chatworkは、「中小企業向けビジネスチャット」を提供しています。1日あたり100万以上のアクティブユーザーによってメッセージがやりとりされています。そのようなChatworkにとっての中核的機能は、「ハイ・トラフィックなメッセージング」となります。それに対してログイン機能はというと、、中核的機能とは言えません。中核とは言えないのですが、ログイン関連機能やセキュリティを業界最高級水準に保つことは、ビジネスチャットとして必須事項です。古くはCAPTCHAサポートや多要素認証サポート、最近ではPasskeyなど、認証・セキュリティのトレンドもどんどん推移していきます。これらに追従していく必要もあります。
ここで、ログイン画面を含む認証機能周りは、外部の専門サービスを導入し、お任せしていく判断が為されました。Chatworkの社内開発リソースは、メッセージングや今後展開するBPaaS事業関連開発に集中させていく、という開発戦略上の判断が為された訳です。
Auth0導入によって、先に挙げた様に、CAPTCHA、多要素認証などの認証関連機能を独自に保守する必要が無くなります。また、Bot検知、不審IP検知といったセキュリティ機能の恩恵にも与れる様になりました。
導入に至る地道な道のり・・・
と、まあ軽く書きましたが、リニューアルを達成するまでには、地道な作業が延々と続きました。
やったこと、その１：まずは、OIDC準拠させるためのリファクタリング
Auth0はOpen ID Connect（OIDC）仕様に準拠しています。Auth0はOIDC Providerとして振る舞います。Chatworkのようなアプリケーションは、Auth0から見ると一つのOIDC Client（Relying Party）に位置付けられます。OIDC ProviderたるAuth0とClientたるChatworkは、OIDCプロトコルに則って認証情報交換を実現します。
Chatworkは元々、ログイン画面を含む認証関連機能を独自に実装していた訳で、チャットルーム画面といった本体機能と”モノリス”状態となっていました。ログイン画面を含む認証関連機能を、(1) Auth0側へ移行する、依って、既存コードは破棄する要素、(2) Chatwork側に残し、OIDC Clientとして振る舞う様に再編成すべき機能要素、(3) 認証と関係ないチャットサービス自体の機能要素、依って、コードの移設が必要だが現行の挙動を原則そのまま再現すべき機能要素、とに分解、分別する必要がありました。Auth0とChatworkはOIDCプロトコルに則って通信することとなりますので、OIDC仕様に準拠したAPIエンドポイントをいくつか新設する必要もありました。
なお、このリファクタリングの成功は、Chatworkの既存仕様をコードレベルで極めて良く理解している古参エンジニアが参画していた事に強く依っています。この布陣は意図的でした。
やったこと、その２：ユーザーマスターデータの移行方式設計と実装
また、ユーザーマスターデータも元々Chatwork側のDBに置かれている訳です。これをAuth0側へ移行する仕掛けが必要です。ここにはAuth0のAutomatic migration機能を用いました。
Automatic migration機能とは、ユーザーが、リニューアル後のAuth0のログイン画面にて初めてログインするタイミングで、当該ユーザーのデータが都度移行される、という仕掛けです。
事前一括移行するとした場合、500万以上のアカウントというデータ量と、Auth0 APIのRate Limitの制限から、移行バッチ実行時間が相当時間にわたることとなると見積もられました。この移行時間の間、サービス全停止するまでも無いにしても、少なくともメールアドレスとパスワードの変更はできない様に機能抑制するか、なにせ一定のご不便をかけることが避けられないと考えられました。
Automatic migrationによる都度移行であれば、そのような停止や縮退運用を避けられます。このような優位性から、Automatic migrationを採用することとしました。
やったこと、その３：Androidアプリ、iOSアプリの改修
Auth0導入案件の当初メンバーは、私を含めてサーバーサイドを専門とするエンジニアのみでした。サーバーサイドの、Webアプリとしてのリファクタリングが一定目処付いた段階で、モバイルアプリ専門エンジニアに参画してもらいました。
モバイルアプリの改修では、App Links/Universal Links対応に苦戦しました。(a) 既存のChatworkアプリに、App Links/Universal Linksに依存した挙動（仕様）が存在する事、(b) OIDCプロトコルでは、Chatworkのドメイン（www.chatwork.com）とAuth0のドメイン（auth.chatwork.com）を跨いだリダイレクトが発生し、この事がApp Links/Universal Linksの挙動に影響を与える事、(c) AndroidとiOSとで、App Links/Universal Linksの挙動（仕様）が異なる事、これら全てに折り合い付けた仕様を見出すのに難航しました。
ちなみに、私の個人的な話ですが、この時開発者人生で初めての、Kotlinコード、Swiftコードのプルリク出しを果たしました（笑）
やったこと、その４：仕様が変わる事のご説明やサポート体制の準備
以上のような改変を行なっていくと、ログイン画面や認証機能に関わるUXにおいて、既存仕様通りとはいかない部位が現れます。挙動としては同じだがUIが変わるもの、意味的目的的には同じ結果をもたらすがUIも挙動も変わるもの、意味的目的的に完全に同じ結果とはならないもの、に分けられます。仕様が変わる機能やUIについては、サポートチームと相談しながら最終的な微調整をしていきました。ヘルプページやサポートマニュアルの更新も同時に進めてもらいました。
やったこと、その５：RFC違反メールアドレスを変更いただくための準備と対応
少々やっかいだった事の一つが、いわゆる「RFC違反メールアドレス」の問題です。Chatworkは、12年前からサービス提供しており、当初はRFC違反メールアドレスを受け付けていました。Auth0は、RFC違反メールアドレスは、バリデーションエラーとして受け付けません。つまり、RFC違反メールアドレスはAuth0へ移行できないのです。RFC違反メールアドレスはお客様ご自身に変更していただくしかありません。このための事前のご案内と実際に変更いただくための導線設計を、プロダクトオーナー、デザインチーム、サポートチームが密に詰めていきました。
メールアドレス変更のための導線を実装することそれ自体はもちろん難しくは無いのですが、お客様に対して、どのようなタイミングや順序でどのような内容、表現、方法でアナウンスしていくと、最も確実にお伝えできるだろうか、このコミュニケーション設計が難しかったと、プロダクトオーナーやサポートチームから聞いています。
これはシステム・インテグレーション案件であった
個人的に、このAuth0導入案件は、「サービス開発における一部機能のアップグレード」と言うより「システム・インテグレーション」と表現した方がより良く実態を表すのではないかと思っています。
元々ChatworkというSaaSと、Auth0というSaaSが存在していました。両者統合してChatworkの新しい認証系を実現することを企画しました。Fit/Gap分析し、現実的に可能な仕様の落とし所を、プロダクトオーナー、サポート、開発の間で調整しました。アプリケーションプログラムとしてのChatworkの諸機能とユーザーデータ、Auth0側諸機能、両者を合わせてトータルでサービスとしてのChatwork（の認証関連機能）を実現する様に、Chatwork側、Auth0側それぞれに対する機能要件の調整を行いました。このような活動は、まさにシステム・インテグレーションと称されるものでしょう。
Chatworkは、創業以来、「自社サービスを内製開発してきた」と言えます。一番最初のバージョンは、現CEOが作った「一つのPHPアプリケーション」だったと聞いています。現在では、PHP製サブシステム、複数のScala製サブシステム、さらにはAuth0、StripeといったサードパーティSaaSも導入され、これらが協調的に動作することで、Chatworkというサービスの全体が実現されています。個々のコンポーネント自体の開発は引き続き基礎として大切ですが、それに加えて、コンポーネント群を俯瞰的に眺める「インテグレーション」の目線感も重要となるような成長段階に達しているのだ、と感じています。
◇
私は6〜7年前まで、まさにSI業界での受託開発を生業としていました。その後いわゆるWeb業界に移って、Chatworkには約3年前に、Scalaプログラマーとして中途入社しました。Auth0導入プロジェクトは、ほぼ入社直後に立ち上がりました。管轄部署にて希望者が募られたのですが、、当初希望者が出なかった（笑）そこで、次のような理由から、率先して志願することとしました。
- 経歴上、実は認証系リプレース案件をやったことがあった。
- 当初から、これはシステム・インテグレーション案件になるだろうことが分かった。
- であれば、私のような年季の入ったSI業界出身者が、役立つ場面も多いだろう。
- 「”Domain Modeling Made Functional”片手に、Scalaアプリケーションをガリガリ開発したいのだ！」という思いも無くは無かったが、まー、それは若手に委ねようと考えた（笑）
結果としては、想定通りにお役に立てたかと自己評価しております。
ID構想、BPaaS事業への布石
実は、Auth0導入の成果を語るにおいては、「Chatworkの認証系機能を、サードパーティSaaSにリプレースした」という側面以外に、「認証系を、Chatwork本体から分離し、疎結合化した」という側面が存在します。Chatworkの立場からは、「非中核機能である認証関連機能が、リプレースされた」というストーリーに見えますが、Auth0の立場から見ると、「認証・ID基盤の最初のClientが、”Chatwork”である」という、別のストーリーが浮かび上がるのです。
Chatworkは、今BPaaS事業に舵を切ろうとしています。
BPaaS事業自体についてはここでは語れませんが、BPaaS事業を支えるシステムサイドの要点の一つが、ID構想となります。
一言で言えば、「複数サブシステムやサービスに跨ったアカウントに関するMDM（マスター・データ・マネージメント）とSSO（シングル・サインオン）」に関する案件です。
私は、こういう一筋縄ではいかなさそうな案件の話を聞くと、アドレナリン出まくりです。さて、どのような移行パスが描けるだろうか、今まさに構想中妄想中です。
