そもそも、ユーザー情報や会社情報は、密結合になりやすい
実装開始時はアプリのDB上にガチガチに実装されていることが多い
なぜ分離したくなるか
- email認証以外追加したい、social認証ならOKだけどそれ以外もガンガン追加したい
- samlやopen ID connectなどの利用
- マイクロサービス
分離時の観点
-
各サービスから、認証認可を呼び出せる
- 認証認可サーバーを建て、API連携する
- 同じドメインであればクッキー管理もできる
-
ユーザー情報を取れる
- ナビゲーションや設定などに使用するユーザー情報やユーザーの属性情報(属する会社情報)、ユーザーの設定情報など
-
セッションの維持(タイムアウト、Single Sign Out)
方法
-
共有データベース
密結合- 問題点、大量のwriteの発生、大量のreadの発生 => redisなどを使う
-
ユーザー情報APIとして切り出し
- アクセス毎のユーザー情報の取得となる場合、毎回アクセスが発生するのでエンドポイント側、アクセス側でキャッシュする必要が生じる
- サービスごとにセッション管理やユーザ情報取得(userやcompanyの情報)のコードを書くのは綺麗でない。gem or apiを作って対応できればよし
問題点
そもそも各サービスに認証認可を考えさせるのではmicroserviceにする意味ないのでは
-
API Gateway pattern
https://microservices.io/patterns/apigateway.html
https://sdtimes.com/apis/securing-microservices-the-api-gateway-authentication-and-authorization/ -
Auth0
apiに任せられる、ユーザーの情報取得は一つサービス作る必要あり
- Auth0の良いところ
プロダクトが大きくなるとやりたい6つのことをやる前提で作られている
Single Sign On
Securely and easily implement Single Sign On for your customers, partners and employees
Universal Login
Standard-based login infrastructure with centralized feature management for websites and native apps
Breached Passwords Detection
Protect your users and services from password leaks.
User Management
The simplest and easiest to use tools to help administrators manage users.
Multifactor Authentication
The most usable and friction-free multifactor authentication experience.
Passwordless
Allow users to login without the need to remember a password.