前回の記事の補足になります。
ログイン状態や認証の管理について
マイクロフロントエンドのログイン状態や認証の管理について下記2つのブログ記事で紹介されている方式を要約した。
- Auth0のKlee Thomasのブログ
- Fixerのブログ
Auth0のKlee Thomasのブログ
Auth0のKlee ThomasのブログではOpenID Connectを利用したSSOでマイクロフロントエンドの認証状態を管理する方法が紹介されている。
下記に記事の内容を要約する。
管理する用のWeb Appを別で用意する方法
マイクロフロントエンドなアプリケーションで認証
マイクロフロントエンドを実装する場合、各フロントエンドは独自のアプリケーションであるため、ユーザーが最初のアプリケーションにログインすると、認証トークンを共有することができない。
しかし、マイクロフロントエンドで構築されたアプリケーションを、ユーザーにとって1つのアプリケーションとして動作させたい。
そのためにも、ユーザーが各フロントエンドを利用する際に毎回ログインさせたくはない。
認証を共有
OpenID Connectを使い、認証を管理する用の別のドメインで働いているアプリケーションを導入することで認証を共有することができる。
上の図で考える。
クライアントが使うアプリケーションをmy.app.comで動かし、認証を管理する用のアプリケーションをid.my.app.comで動かす。
フロントエンドでユーザーが認証する際、ユーザーはid.my.app.comにリダイレクトする。
ユーザーが初めてmy.app.comにアクセスすると、ログイン画面が表示され、認証プロセスが実行される。認証プロセスが完了すると、クエリ内のアクセストークン、IDトークン、リフレッシュトークンを使用して、my.app.comにリダイレクトされる。
このリダイレクトの前に、認証アプリケーションはドメインに保存されているCookieを利用する。そうすることで、その後フロントエンドがユーザーをリダイレクトすると、認証アプリケーションはCookieをチェックして、ユーザーが以前認証が通たことを確認し、2回目の認証を強制されることなくリダイレクトされる。
Silent authentication
上の方法で認証を管理しようとすると、ユーザーは何度もリダイレクトされることになる。
これの解決策は、ユーザーから隠された方法で認証を行うことである。
認証を行い、トークンをwindow.postMessageを使って返すiframeをDOMに加える。
参考
How do you share authentication in micro-frontends
Fixerのブログ
Fixerのブログではマイクロフロントエンドのログイン状態や認証の管理について4種類の方法が紹介されている。
各方法について下記に要約する。
SSOを使う方法
マイクロフロントエンドごとにSSOサービスとやり取りをしてユーザーがログインしているのか、また、どのユーザーなのかといった情報を受け取って認証を行う。
長所 ：ユーザーがどれかのサービスを使用する際にSSOを通してログインしていれば、残りのサービスにおいても自動的に認証されるため、サービスごとに個別に認証する必要がない。
短所 ：サービスごとにSSOサービスと通信した場合、個々のサービスとSSOサービスがそれぞれで通信を行うことになるので、通信トラフィックがかなり大きくなってしまう。
共有データストアに保存する方法
ユーザ認証に関わるデータを全サービスで共有するデータストアに保存し、マイクロサービスを使用する際はそこから認証情報を引き出すという方法。
長所 ：一つのサービスでログインしていれば、その認証情報を全サービスで使いまわせるので、サービスごとにログインしなければならないこともなくなる。
ユーザーのログイン状態が不透明である。
短所 ：データストアを不正なアクセスから保護するためには、サービスとデータストアの間のアクセスはセキュアな通信を通して行わなければならなくなる。
トークンを使用する方法
ユーザー認証にクライアント側で作成されるトークンを使用する方法。
短所 ：ログアウトが難しい。
トークンは署名の期限が切れるまでずっと有効になってしまうため、ずっとログインが行えるようになってしまう。
対策 ：署名を失効させる、トークンを短命にする
トークンとAPIゲートウェイを使用する方法
フロントエンドからサービスに接続する間にAPIゲートウェイを通し、そこで認証や認可などの本来個々のサービスで行うはずだった処理を集約して行う。
長所 ：フロントエンドがサービス群と直接やり取りしないのでサービスが隠蔽されること。
短所 ：実装が複雑。