kubell Creator's Note

ビジネスチャット「Chatwork」のエンジニアのブログです。

ビジネスチャット「Chatwork」のエンジニアのブログです。

読者になる

認証領域は、サービスを使っていただくという根本のCVRに直接影響を与える(「#Offers_DeepDive」にオンライン登壇、「Chatwork」の認証基盤についてお話ししました)

認証グループのエンジニアをやっている田中浩一(@Tanaka9230)と申します。

去る4月23日に、株式会社overflow様主催の、Offers_DeepDiveLayerX/kubellの実例から学ぶ プロダクトが大きくなっても壊れない認証設計とは」に、オンライン登壇させていただきました。

offers-jp.connpass.com

認証グループは、「Chatwork」の認証系+一部セキュリティ系、およびアカウント管理系を担当領域としたフィーチャー・チームです。認証系の中核には「Auth0」というIDaaSを導入していて、その運用も担っています。

登壇では、認証グループが行なってきたこれまでの成果を振り返りつつ、下記のようなお話をさせていただきました。

  • IDaaSを導入することとなった経緯
  • 元々モノリスだった「Chatwork」から、認証機能部位のIDaaSへの移行をどのように進めたか
  • 認証基盤側の責務と、「Chatwork」側の責務とを、どういう考え方で切り分けたか

イベントにはもうひと方、「バクラク」を展開する、株式会社LayerX様のバクラク事業部Platform Engineering部IDチームより、convto氏(@convto)が登壇されました。コンパウンド戦略のもと、当初から複数プロダクト展開してきたLayerXさんのケースと、「Chatwork」からモノリス解体して認証基盤を確立して、複数プロダクト展開に至った弊社のケースとで、同じ様な要求に晒されつつ、異なる解決アプローチを取るに至っている対比が面白い内容となりました。

こちらから、Offersに会員登録いただければ、アーカイブ動画が視聴出来るとのことですので、よろしければ見てみてください。

  ◇

本記事では、当日お話ししきれなかったかなー、という点をいくつか補足いたします。技術的に細かいことも言及します。

1. IDaaS導入という道を選んだ理由

convto氏の発表を伺うと、LayerXさんのケースでは、

  1. 最初から認証基盤は切り出されていた。
  2. 当初はパスワード認証のみをサポートしていた。
  3. そこに、例えばOAuth2対応したい、という要求が発生した。
  4. 認証系の既存実装(≒ログイン画面周り)は活かしつつ、OAuth2対応部位を付加するアプローチを考えた。

上記を達成するために、Ory HydraというOIDC/OAuth2をサポートするライブラリー/サービスを導入した、とのことです。『個々のプロダクトから独立した認証基盤は、(独自実装したものが)最初から存在していた。その認証基盤を如何に拡張していくか?』という問題設定だった、ということですね。

弊社のケースでは、『認証基盤を切り出す』こと自体が目的の一つでした。加えて、『ログイン画面周りのセキュリティ対策を含む認証基盤の保守開発や運用は、"専門家"にお任せしよう』という方針がありました。後者の方針も理由となって、『「Chatwork」の既存実装から認証機能部位をforkしつつ、Ory HydraあるいはAuthleteを導入する』といった様な解法では無く、『IDaaS導入』という選択をするに至っています。

ちょうど、フリー株式会社様による、『なぜ、どのようにfreeeの認可基盤にAuthleteを採用したか』、という記事を知ったのですが、比べると三社三様な様子がめちゃめちゃ面白いですね!また、Authleteに関心ある方の参考にもなると思います。

www.authlete.com

2. 認証基盤側とプロダクト側とで、データ上、責任範囲をどう線引きしているか

発表中もお話しした点ですが、紆余曲折あるものの、最終的に(現時点では)、認証基盤の責務は、もっぱら「個人としてのアカウントの本人の認証」に限ることとしていて、認可的な責務は、各プロダクト側でそれぞれ対処する、というポリシーとしています。

さて、具体的には、アカウントのどの様な属性項目を"認証基盤の持ち物"としているのか、というと、「Chatwork」の画面の右上にメニューがありますが、そこから「アカウント設定」を開いてください。

はい、この画面とこの画面で扱ってる「登録名」、「メールアドレス」、「パスワード」、「2段階認証設定」が、"認証基盤の持ち物"となります。わかりやすい!

ちなみに、この「アカウント設定」画面の(再)開発がどの様に為されたのかについての発表があります。ご参考まで。 speakerdeck.com

3. 認証領域は、サービスを使っていただくという根本のCVRに直接影響を与える

ここ、とてもとても大事なのに、当日発表中全く伝えられてませんでした!!認証という領域は、何をやっても基本的には"当たり前品質"であり、地味な世界です。ですが、実はSign-upやSign-inのコンバージョンレートに直接影響を及ぼす領域なのです!

例えば先月初頭に、Sign-in/up導線のまさに地味な改善をリリースしています。ある別の施策を進める中で、Auth0の挙動を踏まえると、今回リリースした様な導線改善に応用できるじゃん!と、認証グループの開発チームが気付いて、PMを通して提案、採用されリリースに至りました。結果、ある分母に対するSign-up率を有意(約10%)に向上させることができました!これは、せっかく「Chatwork」を利用しようと思っていただいたのに、最後まで到達できなかったお客様がいらっしゃって、そういった方を一定救うことへ繋がったことを意味します。すごいじゃん!

「認証」の話から外れますが、この施策のもう一つのすごいところは、開発チーム発の提案だった、という点です。なぜ開発チーム側から、結果として実際にCVR向上に繋がる様な施策提案が可能だったのか、というと、次の記事の様な試みをずっと行なってきたからだと考えています。こちらもよろしければどうぞ。 creators-note.chatwork.com

  ◇

今回は以上です。引き続き、kubellの取り組み、認証グループの取り組みにご注目ください。