🗝️

Auth0 で Google みたいなマルチアカウント構成っていけるの？

2022/10/07に公開

認証

雑記です。

これの調査をしたので、記録します。

Googleのアカウント管理のような「複数ユーザー間をスイッチする」ような仕様をAuth0で構成する方法を調査したログです。調査に至ったプロダクトでは採用しない方針で考えたので、ボツ案になったんですけど、思考整理のためにも記録しておきます。

結論

不向き。初手、大規模構想を実現するようなリリースプランなのであれば候補に挙げてもいいけど、そもそも向いてないのと、アクティブユーザー数十人前後のサービスを想定しているのであれば、過剰な構成になるのであまりお勧めしません。

やるなら Clerk.dev みたいな、マルチアカウントを前提としているような別 IDaaS を使うべき。

基本方針

IdP (Identify Provider) と SP (Service Provider) を分けて Web API で疎結合するサービスで利用
OAuth2.1 をベースとした OIDC (OpenID Connect) 構成でマルチアカウント管理を行いたい
管理方法やスイッチ方法は Google みたいな感じにしたい
SP は Single Page Application で VueJS をつかう

検討したやり方

1テナント:Nアプリケーション　→ 不可

Auth0 は、契約単位を「テナント(Tenant)」として、テナント内で管理される認証用エンドポイントを「アプリケーション(Application)」として運用します。
テナント単位でドメイン付与が行われ SPA / ネイティブアプリ / Machine to Machine ... といった、用途にあわせてアプリケーションを用意する、というような感じです。

↑を前提に、同一ドメイン配下で、1つのクライアントIDで、ユーザーDBも共通、といった仕様で、1端末で複数ユーザーを識別可能かどうか、という検証をしました。

まぁ OIDC の構成を理解しているとやる前から無理なことはわかっていて、半信半疑で調査をしましたけど、SDKが提供するメソッドも確認したのですが、ユーザー間を識別したり、切り替えたりするメソッドも提供されていないので無理なことがわかりました。

ログインセッション管理の問題で不可

OIDC、厳密にはOAuth2.1ベースの Autorization Code Grant with PKCE での手続きにおける問題なのですが、アクセストークンを発行するために IdP にリダイレクトしてログイン認証を行うことで、IdPでログイン済を示すセッションが端末に付与されることを前提にアクセストークンが発行されます。

IdPでのログインセッションと端末を紐づけるために、ブラウザのCookieを利用するのですが、「セッション:ユーザー」という関係性のなかでマルチユーザー管理を行いたいという場合には、想定できることとして、ログイン済みユーザーごとにユニークなCookieが払い出されるべきです。

Auth0の場合、別々に払い出されることはなくログインのたび、セッションの上書きを確認したので 複数ユーザーのログイン状態をIdPで維持することはできない ようです。
まぁ、そりゃそうですよね、という話ですが、今回の目的では難しいことがわかりました。

Nテナント:Nアプリケーション → 一応、可

前段のセッション管理の問題を解決するためには「テナント=ドメイン」という運用になるので、テナントを分けてしまえば、同一のSDKの中で、ドメインを切り替える仕組みを作ることでCookie管理を物理的に分けることができるので、擬似的にでもマルチユーザー管理ということが可能になります。

で、冒頭の「不向き」という話なのですが、マルチユーザーのロールごとでスイッチする、みたいな仕様構想があるのであればまだしも、"マルチ"と表現されるユーザーの数が特定できない仕様が想定される場合には、その分だけテナントを用意しないといけないので、Auth0の採用は現実的ではありません。

Cookieで管理されるユニークキーを管理できる単位が、ドメイン=テナント、になるので、10ユーザーまでマルチ管理できますよ、と言う場合には、10テナント=10契約が必要になるということになります。

Auth0 を使わないと言う場合

ここまで来て、マルチユーザー管理は不向きとわかったので、別IDaaSを検討していくわけですが ...

Auth0 は日本語対応
Auth0 のSDK対応幅は格段に広い（Vue, Laravel, MySQL は対応しているのでWebアプリ開発コストがかなり軽減される）
Auth0 の開発文献やフォーラム記事が豊富

...といったメリットは、見て見ぬフリはできずで。他IDaaSに、同レベルのメリットはなかったりするんですよね。
こんなニッチな要件は無視して、認証周りですし、あんまりトリッキーなことはしない方が良いと個人的には思いますね。

湿っぽい記事ですが、ログっておきます。