分離されたフロントエンドWebアプリケーションで認証およびリダイレクトする方法
結合されたWebアプリケーションがあります（同じアプリケーションから提供されるフロントエンドとAPIバックエンド）。それは私たちのニーズにはうまく機能していますが、フロントエンドとバックエンドを完全に分離することになる違いに興味があります。
認証リクエストの処理がこのアプローチでどのように機能するかについて、特に疑問に思っています。現在、リクエストを別のページにリダイレクトするオプションがあります。つまり、/dashboardページをクリックすると、Cookie内のトークンが認証されない場合に/loginにリダイレクトされます。
単一のアプリケーションを介して実行されるすべての要求なしで、それはどのように処理されますか？
/apiパスからバックエンドサーバーへの要求を渡すリバースプロキシを作成するとします。しかし、他のすべてはフロントエンドに提供するものによって処理されます。私がこれについて正しく考えている場合、フロントエンドのページに対する各リクエストはある意味「無制限」であり、バックエンドハンドルから認証情報をリクエストした後、正しいページにリダイレクトします。
/dashboardから/loginの例に戻ると、このフローに従いますか？
- ユーザーが
/dashboardurlをリクエスト - NGINXは、ダッシュボードSPAに必要な静的リソースを提供します。
- フロントエンドJavaScriptコードがバックエンドエンドポイントから認証情報をリクエストする
- ユーザーのCookieが認証されない場合は、JavaScriptを使用してユーザーを
/loginにリダイレクトします。
私は正しい軌道に乗っていますか、この問題を解決するより良い方法はありますか？
現在とほとんど同じように処理します。 APIを分離しても、ウェブサイトにサーバー側のコードがまったくないわけではありません。
具体的には、認証されていないユーザーによるJavaScript、画像、HTML、およびその他のコンテンツへのアクセスを拒否できるようにする必要があります。
これを行うには、現在のサーバー側の認証コードを保持して、ログインとトークンの生成を処理します。ログインが成功すると、トークンはJavaScriptによって読み取られ、APIへのリクエストを認証するために使用され、ページリクエストを認証するためにWebサーバーに渡されます。
私がやった方法は、OAuth2サーバーで次のとおりです。
- クライアントがコンテンツサーバーに到達します。
- クライアントにはアクティブなセッションがなく、コンテンツサーバーへのコールバックで認証サーバーにリダイレクトされます。
- クライアントは認証され、認証トークンを使用してコンテンツサーバーにリダイレクトされます。
- コンテンツサーバーは、認証サーバーでコンテンツトークンを直接検証し、クライアントへのアクセスを許可します。
現在、認証は別のサーバー上にありますが、コンテンツサーバーは引き続きCookie経由でセッションを追跡する必要があります。