メールアドレス以外の識別子でログイン！ログインIDユーザー機能の開発舞台裏を紹介します

どうもお世話になっております、バクラク事業部Platform Engineering部でID基盤関連のシステムを管理するチームに所属している id:convto です。
最近ペット可物件に引っ越したので、ついに猫を飼う計画を進めています。ファントムキャットタワーを買おうとしていた時期からは信じられないほどの進捗ですね。

バクラクでは先日、メールアドレスを持たない従業員の方向けに、メールアドレス以外の識別子を持つアカウントをサポートする機能、「ログインIDユーザー」機能をリリースしました。
今回はこの機能について、提供にあたって考慮した内容や、おおまかな設計などについて紹介したいと思います！

ログインIDユーザー機能とは

以下のプレスリリースにてご紹介しています。

bakuraku.jp

バクラクでは従来、ログイン時などのアカウント識別子としてメールアドレスを使用しておりました。ただ、業態によってはメールアドレスを全てのユーザに配布していないといった理由により、バクラクのシステムが利用できないケースがありました。典型的には、パート/アルバイトなどの雇用形態に応じてメールアドレスを配布しない、といったことが挙げられます。

このようなお客様にもシステムを利用いただくため、メールアドレスによらない識別子を提供することでバクラクのアカウントを作成できるようにした、というのが今回の機能の趣旨です。

メールアドレス以外の識別子サポートにあたって、考慮すべき観点

いくつかの観点がありますが、特に重要なのは以下の二つの観点でした。

識別子の設計
- 最低限一意であることは必要で、ほかにもいくつかの性質が必要そう
認証要素が減るケースのカバー
- 受信可能なメールアドレスがなくなるため、いくつかのユースケースで以前より認証要素が少なくなります
- たとえばメールでワンタイムトークンを送付し所有を確認するような処理がバクラクシステムで存在したため何かしらの対応が必要

この 1. 識別子の設計(以降この識別子についてログインIDと呼称します) と 2. 認証要素が減るケースのカバーについて、それぞれ一定の整理ができないとこの機能は提供できなさそうです。

これらについて、今回の機能開発にあたって整理した内容を紹介していきます。

識別子の設計

ログインIDの利用シーンを整理し、必要な性質を満たす識別子を検討しました。

利用シーンの整理

まずは、ログインIDが利用されるポイントをざっと整理します。主に以下のような利用をされるでしょう。

管理者が従業員を招待する際にログインIDを設定する
従業員がログイン時にログインIDを入力する
認証システムがログインID + 特定の認証要素によって認証する

ログインIDはこれらの利用に耐えうるものである必要があります。

必要な性質

利用シーンから、ログインIDには以下の性質が求められていると整理しました。

一意(ユニーク)であること
ある程度短く、記憶しやすいこと
パスワードマネージャとの相性がいいこと
- たとえば複数要素で識別する構成などのとき、複数フォームに分かれていないことなど*1
ユニーク性の境界が管理者業務とマッチしていること

最後のユニーク性の境界が管理者業務とマッチしていること、の部分はすこしイメージが難しいかもしれませんが重要な観点なので補足します。

たとえば、ある企業が社内で運用している従業員番号 A0001 を管理者がログインIDに設定しようとしたとします。このとき「ログインID A0001 はすでに他社に利用されています」のようなエラーがでたら管理者業務はどうなるでしょうか。

管理者は、このようなエラーが出ると、社内で運用している従業員番号をログインIDとして設定するのを諦めざるを得ません。別途なんらかの採番体系を考える必要がありますし、変更しても再度他社が利用済みの空間と衝突しない保証はありません。

このような問題が考えられるため、管理者の業務を考慮した上で運用しやすいユニーク境界とする必要があります。

ログインIDのコード体系

必要な性質から、以下のコード体系としました。

まず記憶や認知のしやすさのため、ランダムIDなどでなく意味のある値で構成しています。

つぎに業務にマッチしたユニーク境界とするため、事業者ごとのコードを末尾に持たせています。この場合loginNameは事業者内でのユニークであればよいため、先ほど紹介した他社とログインID空間が衝突するようなことが起きません。

また、パスワードマネージャーとの相性を考え、結合させて1つのIDとして取り扱っています。これは、入力フォームが分かれるとパスワードマネージャ側で入力項目分の設定が必要になり、若干使いづらくなるためです。事業者ごとのサブドメインなどサポートしているサービスであればそこから判断するのもよいかもしれません。

(余談ですが結合文字もいくつか議論の余地があり、変遷をへてハイフン(-)に着地しました)

認証要素が減ってしまうパターンのカバー

さて識別子の整理がついたので、次はメールアドレスがないことにより減ってしまう認証要素をカバーしなければなりません。

まずはメールアドレスがあることによって所有の確認ができていた部分について、それをログインIDユーザー向けに似たような安全性で提供できるか考えていきます。

今回は従業員アカウントの作成フローについての整理を紹介します。

メールアドレスによってカバーしていたフローの確認

たとえば従業員のアカウント作成などで、ワンタイムトークン付きのリンクをメールアドレスに送付し、それを踏んでもらうことで所有の確認をするケースがあります。

これにより、メールアドレスを所有している本人であることを確認したのちに安全にパスワード設定をさせることができます。

以下のようなシーケンスです。

このケースでは、ワンタイムトークンによる所有の確認のおかげで、パスワード設定を行うのが本人であることが確認できます。

ログインIDユーザーの場合ではワンタイムトークンをメールアドレスに送付することはできません。どのようにすれば良いでしょうか。

ログインIDユーザーの場合

基本的には「アカウントを有効化してパスワードを設定するさいに何らかの認証要素を課す」ことでメールアドレスがなくなった部分のカバーをする方針で考えます。

認証要素の選択肢はいくつかありますが、運用の簡単さなどから考えて自動生成される初期パスワードのようなものを認証要素として設定してみます。

実装や整理の際にいくつかのプロダクトを参考にさせていただきましたが、多くのプロダクトが似た整理となっていました。

今回のログインIDユーザーの従業員アカウント作成時は以下のようなシーケンスとしました。

ここで3, 4のあたりが気になる方がいると思います。

バクラクから従業員への初期パスワードの連携をどうするかは、とりうるオプションがいくつかあります。今回紹介しているのは管理者を経由して従業員に伝えるパターンですが、ほかにも従業員の個人の連絡先を指定してシステムから初期パスワードを送るパターン、などがあります。

管理者を経由する場合、管理者も従業員の初期パスワードを知ることになります。ただ、管理者はもともと各種データの読み書きが可能なため、わざわざ初期パスワードを悪用する動機はほぼないと考えられます。

個人の連絡先を利用する場合、アカウント作成時のみとはいえ業務システムに関するメールが個人の連絡先に飛ぶことになります。企業の運用によってはこのオプションは統制上選択できないこともあるかもしれません。

連絡手段によって想定されるリスクも異なるため、企業の運用に合わせていくつかのオプションから選択できるのがよいと考えています。

まとめ

ログインIDユーザー機能の提供にあたり、メールアドレス以外の識別子をサポートする際の考慮点と対応策を紹介しました。

識別子の設計では、ユースケースから求められる性質を整理しつつ、お客様業務になじむような識別子の形式を決定しました。

メールアドレスがなくなることにより認証要素が減ってしまうようなパターンでは、各ユースケースごとに何らかの認証要素で代替する、もしくは管理者による操作で解決していただくような整理としました。

今回は紹介しませんでしたが、ほかにもいくつか考慮した点はあります！たとえば、ログインIDユーザーは性質上強い権限を必要としないことから、管理者などの一部強い権限をもつロールにはなれないような制御があったりします。細かいところも含めて、安全に使っていただきつつ業務負担が減るよういろいろ頭を使いました。

お客様業務についてのヒアリングなどにも同席させていただき、フィードバックをいただきながら機能開発しました。無事リリースできてさまざまな企業様にお使いいただけることがとてもうれしいです。