こんにちは、認証基盤のサーバサイドエンジニアをしている佐草です。現在弊社では、クライアント認証機能の開発においていくつか課題があり、そのため新規に認証基盤を構築しました。今回の記事では認証基盤をどういった経緯で構築し、どういった点が難しかったかなどを紹介したいと思います。

登場人物

用語	解説
クライアント	求人募集をする企業様
ユーザー	クライアントに所属する個人
IDaaS	Identity as a Service 認証機能を提供するSaaS
Auth0	Okta社が提供するIDaaSの一種
管理画面	クライアント向けに提供するサブシステム

ディップでの認証事情

ディップのサービスには多様な管理画面が存在し、日々多くのクライアントにご利用いただいています。クライアントが管理画面にアクセスする際、まずはそのサブシステムのログイン画面で認証を行ってから利用することになります。しかしこのログイン画面、各サブシステムごとに開発を行っており、それによりいくつかの課題が存在しています。

開発コストの増加
ユーザ管理の責務がふわふわ
ログイン画面がサブシステムごとに異なる
セッション管理を各サブシステムでおこなっているため、ログインし直す必要がある

ディップではAuth0を用いてこれらの課題を解決できるか検証を行なっています。

IDaaS

採用情報を取り扱うディップのサブシステムにとって認証・認可は必須の機能ですが、自前で実装する場合コストや時間が大きく、リスクもはらんでいます。そこで注目したのが認証・認可機能を提供してくれるIDaaS (Identity as a Service)です。

比較検討

IDaaSは有名所だとCognitoやFirebase Authenticationなどが存在します。ディップ内でもどのIDaaSにするかの比較検討を行いました。それぞれ以下のようなメリットがありました

Cognito：管理のしやすさ、サポート（弊社のインフラはAWSに寄せることが多いため）
Firebase Auth：コスト面
Auth0：機能の豊富さ、サポート

Auth0に決めた理由

今回クライアント認証基盤を構築するにあたり、既存の管理画面のユーザを認証できることが一番の要件でした。 JSONやCSVでの移行も検討しましたが、クライアントは増え続けるため継続的にデータを同期する必要があります。そこで既存の管理画面のDBを参照できるAuth0のカスタムDB接続という機能に注目しました。カスタムDB接続は、認証情報をAuth0自体に保存せず、認証時には自社のDBを参照できる機能です。公式ページ参照

認証基盤導入による嬉しさ

クライアント：ログイン体験の向上

クライアントにとっては、スムーズに認証を行えることが理想です。多様な管理画面は便利な一方で、利用するサブシステム数が増えるほど、ユーザーが管理しなければいけないアカウント情報が増えたり、ログイン画面がサブシステムごとに異なってわかりづらいなどの問題があります。また、サブシステムごとに別アカウントでログインしなければいけないという煩わしさなどもあります。クライアント認証基盤を用いることで、IDやパスワードが管理しやすくなり、シングルサインオンなどを用いて複雑化が緩和されます。

開発者：担当領域に注力できる

サブシステムの増加やアカウント数の増加、サブシステムへのアクセス経路が複雑化していくと、アプリケーションごとに認証機能を開発したりする部分の負荷が大きくなっていきます。 Auth0が提供する仕組みを利用することにより、システム管理者や開発者はこれらの個別対応から解放され、開発コストも軽減されます。また、現状ではユーザ情報を参照し認証機能を提供しているだけですが、今後の展望としては登録・更新・削除の機能をもつことでユーザ管理の責務を担うようにしたいと考えています。

難しかったポイント

複数の企業に所属するユーザ

クライアントの中には複数の企業に所属するユーザがおり、データもメインの管理画面で扱いやすい形式（ユーザx所属企業分のレコードが存在する）となっています。認証基盤を利用する人からすれば、認証したいユーザのデータ形式に関わらず一意に認証する必要があるため、これらのユーザを他の管理画面で取り扱う時、認証基盤側でマージする必要があります。また、Auth0はMAU(Monthly Active User)で金額が変わってくるため、認証対象をユーザx所属企業分とすると膨大なMAUとなってしまいコストが増加してしまいます。これらの課題を解決するため、ディップではAuth0カスタムDB接続で自社のDBを参照する際に、DBを直接参照するのではなくAPIを介して照合する仕組みとしており、さらにそのAPI内でユーザのマージを行なっています。また今回ディップでは利用していませんが、こういったケースではAuth0のアカウントリンク機能も活用できるかもしれません。

IDトークンの設計

Auth0を用いてIDトークンを発行する際、任意のクレームを設定をすることができます。 OIDCに則った形で基本的な情報は埋め込まれるのですが、Auth0のActionsを使用することでそれ以外の情報も付与できます。例えば弊社ではそのユーザがどの企業に所属しているかという情報を追加しています。その他の情報もサブシステムからの要望で追加したいですが、認証基盤の将来の姿を考えた際、ひとつのサブシステムに傾倒してしまうと拡張性が下がるというでデメリットもあるため追加は慎重に行う必要があります。