スプリングマイクロサービス、ステートレスセッション、角度および静的ファイルサービス

Question

マイクロアプリケーションに分割された大規模アプリケーションのバックエンドを設計しています。ユーレカ、Zuulとなど、私は4つの補助金の種類をサポートしていのOAuth2認証サーバを実装している：私はそのツールで春クラウドを使用しています。それは問題なく動作しています。

は、その後、私は許可されていない場合、バックエンドはログインページにリダイレクトする必要がありますようにhtmlファイルとを提供するために頼まれたと強く私はセッションを使用しないことをお勧めします。私は、セッションスプリングがないと実際に何が起こっているのかを知っていると思ったので、最後ににセキュリティコンテキストを構築することを決定するトークンが必要です。

私はこの問題について調査を開始しました。私は、Spring Security and Angular JS tutorialの例では、の角の中で、ルーティングとリダイレクトがui-routeの助けを借りて行われることを示しています。私はgithubでいくつかのプロジェクトをスキミングし、リダイレクトには角度を使用していました。

完全にステートレスなセッションでバックエンドを使用してリダイレクトすることはできますか（これはあまりにもダメですが、それ以外の表現はできませんでした。可能であれば、例はありますか？

Answer 1

内部セキュリティにOAuth2を使用している場合は、セッションのようにトークンの存在を処理して、すべてのサービスを制御するためにoauthを使用することをお勧めします。

4つの許可タイプのいずれかでアクセストークンを生成したとします。 ResourceServerConfigurerAdapterの安全なスプリングクラウドリソースにアクセスするには、そのトークンをAuthorization: Bearer <token> HTTPヘッダーに渡すか、/service/endpoint?access_token=<token>のような取得パラメータとして渡します。

トークンがユーザーに関連している場合（ユーザーなしでクライアントを認証できます）、securityContextからOAuth2Authenticationを取得すると、その詳細にアクセスできます。

さらに、アクセストークンがSpringクラウドセキュリティのデフォルトでサポートされているJWTである場合、承認サーバーに実際のトークンストアを提供する必要もなく、また、リソースサーバーから認証サーバー上のユーザーエンドポイントを要求する必要もありませんJWTの内部で出荷されるため、ユーザー情報を取得します。

"セッション"（とその状態）に関するすべてはアクセストークンの内部に格納されています。アクセストークンは簡単に渡すことができ、複製の混乱を招くことなく拡大縮小できます。

セキュリティよりもステートレスなセキュリティを得ることはできません;）