以前に内製で作られていた認証基盤を IDaaS(Auth0) での認証基盤にリプレイスしました。
基本的にリプレイス自体は大きな問題を起こさずに遂行できたのですが、その後に起きた事象がなかなか興味深かったので書いていきます。
似たようなことを考えている人には少し参考になるかもしれません。
対象読者
- これから認証基盤をリプレイスしようと試みている人(内製 -> IDaaS)
実際にやったことの概要
Before
- 内製の認証基盤で認証を行なっていた
- よくある Email + Password の形式
- 秘匿情報を内部の DB に持っておりの危殆化リスクがある
After
- 認証に関しては Auth0 の方に機能を移譲
- 諸々の事情(詳細は割愛)があり Google 認証 or Passwordless(メールで認証コードを送信)の形式に変更
- Password を全く持たない形式にした
リプレイス後に起きたこと
「ログインできない」系のお問い合わせが起こる
UI の側面における変更点としては、よくあるログインフォームからAuth0 が提供するログインフォームへの変更のみでした。
しかし、
- 旧形式(Email + Password)の方法がないこと
- 2 通りの方法(Google 認証 or Passwordless)が提供されていること
あたりが起因であろう問い合わせが 10 件ほどありました。
具体的な問い合わせの原因としては下記のようなものが挙げられます。
- 他のサービスと同じ要領で Google 認証をしてしまったが、実際にサービスを利用しているアカウントとは違う
- エイリアスの Email(参考)で登録されたアカウントで Google 認証を試みる(Google 認証はエイリアスの付与されていないアドレスのみで可能)
- Passwordlessの方式で認証コードが送られてから入力するまでの期間が長くて期限切れになる
基本的には顧客側のリテラシーによるもの、と言えるでしょう。
今回は toB のプロダクト(ユーザー数が少ない)というのもあり、顧客担当者を経由して自身が応対することでも十分対応できました。
しかし規模が大きくなったり、toC のプロダクトだったりすると問い合わせが捌き切れない懸念があります。
認証基盤のリプレイスは基本的に UI や仕様を変えないことが望ましいと言えます。あるいはリテラシーの低い方でも理解できるレベルの仕様にするといった配慮が必要です。
大口顧客が戻して欲しいと怒る
toB プロダクトあるある(?)かもしれませんが、プロダクトから取得できる情報(レポートデータなど)をスクレイピングで取得し、Excel データなどにまとめる。といったことを行なっている顧客がいました。
もちろん旧認証基盤前提でスクレイパーは実装されていますので、認証基盤を新しくするにあたり、そのスクレイパーは正しく動作しなくなります。
通常ですと新認証向けにスクレイパーを修正する、または Web API(自社で提供済み)を用いた情報の収集方法に切り替える。といったことを顧客に求めます。
しかし顧客とのパワーバランスによっては先述のような対応を行ってもらえないこともあります。今回はまさにそのような事例でした。
一応顧客側を配慮したリリースフローを組みました。具体的には下記のようなことを事前に行っています。
- リプレイス 1 ヶ月前に認証基盤が変わるので Web API を用いて情報収集を行ってもらう旨を、プロダクト内のお知らせ機能で通知
- 加えて、顧客へ直々に同様の内容のメールを送付
十分な期間(1 ヶ月)を設けたのですが、リリース後に「旧認証に戻して欲しい。さもなくば縁を切る。」といった旨の連絡が来てしまいました。大きなお金を落としてくれる顧客である以上、要望には従うしかありません。
結局、特定の顧客にかぎり旧認証基盤での認証を行える状態にしました。とどのつまり認証基盤は完全にリプレイスしきってはいないのです。実装上は疎な結合にはなっていますが...
このままでは引き下がれないので、なんとか対応方法を考えています。具体的には下記のようなものです。
- 自身が顧客側に出向する形で、Web API を用いた収集方法の実装を行う(コードに責任がつくのでおすすめはされなかった)
- Web API を用いた収集方法への移行ガイドラインやサンプルの実装などを資料として送付し、円滑に対応できる状態にする
終わりに
同じ部署の方々にこの話をしたところ「リプレイスって互換性とセットだよなぁ」といったことをぼやいていました。確かに自分の配慮が足りなかったなぁと。
今回はその反省というか体験をシェアする気持ちで書きました。
誰かの仕事の参考になれば幸いです。