9
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

ディップAdvent Calendar 2021

Day 18

Auth0認証を組み込む方法を考える

Last updated at Posted at 2021-12-17

Auth0

最近はIDaaSと呼ばれる、アプリケーションに必要な認証周りを提供してくれるSaaSがでてきており、大変便利な世の中になりました。一番気を使う認証部分を丸投げできるのはホントと助かります。

Auth0 は、IDaaSの中でもWebアプリケーションに組み込みやすく、カスタムの幅が広いのが特徴です。

今回はAuth0の導入について取り上げたいと思います。

ただAuth0導入すると言っても、アプリケーションの状況によって、考えるべき視点がありますので、それらの視点と、パターン別にどう考えられるかをまとめてみます。

考えるべき視点

大きく3つ挙げてみました。

####ユーザーデータベース
→ ユーザーを認証をするためには、認証で参照するデータベースが必要です。それをどこで管理するかを検討します。

####アプリケーションとの連携
→ ユーザーを認証した後、その認証情報をアプリケーション側で扱う際に、Auth0側およびアプリ側で、それぞれどんな情報を持つべきかを検討します。

####ログインセッション
→ 認証されたユーザーが、現在もログインしているかどうか = ログインセッションの管理手法について検討します。

上記視点について、ありそうなパターンで考えてみました。

##新規アプリケーションに1からAuth0を導入する場合
このパターンが、Auth0を導入する際に一番考えることが少なくなるでしょう。全部Auth0に任せてしまいましょう。

####ユーザーデータベース
Auth0側でデフォルトで存在するデータベースが用意されているので、それを利用することができます。Auth0提供のWeb管理画面で、登録から削除まで操作可能です。各種APIも用意されていますので、アプリケーション側からでも操作可能です。

また認証以外の、名前や会社名など任意の拡張情報も、json形式で user_metadata に保持できます。
権限など書き換えられては困る情報については、app_metadata に保持することができます。

####アプリケーションとの連携
Auth0側のユーザー識別子( user_id )は、 auth0| で始まる、16進数での文字列になっています。アプリケーション側では、その user_id に紐づくデータ設計にする必要があります。

####ログインセッション
Auth0側でログイン状態を確認できるSDKが用意されていますので、アプリケーション側は、Auth0側で用意されたSDKやAPIを利用するのがよいでしょう。

##既存アプリケーションにAuth0を組み込む/リプレイスする場合
既に認証が存在する既存アプリケーションにAuth0を導入する場合は、既存の認証に何らかの理由があってでしょうから、Auth0側に何をしてもらうのかを定義する必要があるでしょう。

例えば、既存のアプリケーションA、アプリケーションBで、それぞれのユーザーデータベースで認証しているものを、全てAuth0に統合一本化する = SSOを実現したい、なんてパターンを想像して考えてみましょう。

####ユーザーデータベース
AとBではそれぞれ独自のユーザーデータベースが存在するので、認証を一本化するにあたり、どちらのユーザーデータを引き継ぐのか、両方マージするのか、SSOとして新しいIDを発行し使用するのか等、十分に検討しましょう。

Auth0では、独自のデータベースへ接続して認証する手段(javascript)もありますし、Auth0のデータベースへインポートする手段もありますので、既存アプリケーションの認証情報を引き継ぐ事もできます。

####アプリケーションとの連携
ABどちらも一本化した認証を使う場合、認証された情報から、ABそれぞれのアプリケーション独自のユーザー識別情報を取得できるようにする必要があるでしょう。一番の肝ですね。

Auth0で用意されるユーザーデータベースでは、ユーザー毎に app_metadata にユーザー識別情報を保存することができます。

Auth0のRulesを使用することで、app_metadataに対して、アプリケーション毎にアクセスできる情報を制限する等も可能です。

####ログインセッション
既存アプリケーションのログインセッション管理をリプレイスすることは、影響範囲も大きく、恐ろしく骨が折れます。

ですのでアプローチとしては、認証のみAuth0で行い、認証成功したら既存アプリケーション側で対応するユーザーのログインセッションを生成、あとは既存アプリケーションの仕組みをそのまま利用する形が現実的ではないかと思います。これはSSOとしても一般的なやり方ですね。

##まとめ

今回はAuth0を導入検討するにあたり、考えなければいけない触りを記載しました。実際に考えなければならないことは、アプリケーションの数だけバリエーションがあるでしょう。

そして今回は省いていますが、コスト面も考えなければなりません・・・。それなりに利用者がいるとかなりかかります。

Auth0はとても優秀でおすすめできますが、導入前に考えることの参考になれば幸いです。

9
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
9
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?