Spring WebFlux Securityで複数の認証方法を実装するにはどうすればよいですか？

私はWebfluxが得意で、oauth2で多くの作業を行ってきたので、いくつかの質問に答えてみます。

1）トークンベースのアプローチで認証の名前と資格情報を入力するにはどうすればよいですか？httpBasicを使用するようにSpringSecurityを構成すると、すでに入力されています。なんらかのフィルターが必要ですか？

トークンに資格情報が含まれることはありません。トークンは、認証が行われた後に発行されるものです。したがって、通常は発行サービスに対して認証します。そのサービスに対して自分自身を認証した後、トークンが発行されます。

oauth2トークンの場合、トークン自体は単なるランダムな文字列です。ユーザー自体に関するデータは含まれていません。このトークンが（適切なヘッダーを使用して）SpringSecurityを使用するサービスに送信されるとき。Spring Securityには、基本的にトークンが有効であることを確認するトークンフィルタがあります。通常、トークンを発行者に送信し、「このトークンは有効ですか？」と尋ねます。

異なるjwtを使用する場合、jwtには発行者、スコープ、件名などの情報が含まれている必要がありますが、基本的に同じことです。jwtを発行者に送信することで検証する組み込みのフィルターがあります（またはサービスが発行者からフェッチするjwkを使用して、追加のリクエストを行わずにjwtの整合性を検証できるようにします）。

2）資格情報の取得元を認証マネージャーで区別するにはどうすればよいですか？userRepositoryと（見つからない場合は）technicalUserRepositoryも検索する必要がありますか？

通常、異なるURLパスに対して複数のSecurityWebFilterChainsを定義します。私はWebfluxSpring Securityでこれを行っていませんが、通常のSpringアプリケーションでこれを行う方法であり、ここでは違いは見られません。あなたが何かクレイジーな習慣をしているのでなければ。

3）SecurityContextRepositoryをオーバーライドする必要がありますか？すべてのチュートリアルがそれを行いますが、そうする理由はわかりません。正確には何ですか？このソースは、「SecurityContextRepositoryは、ユーザーのユーザー名とパスワードを比較する通常のSpringSecurityで提供されるuserDetailsS​​erviceに似ています」と述べています。しかし、彼はReactiveUserDetailsS​​erviceを意味していると思います（ちなみに、UserDetailsS​​erviceもReactiveUserDetailsS​​erviceもそれを行いません。ユーザー検索のためだけです）。

ここでの答えはおそらくノーです。Spring security 4のoauth2、特にJWTのサポートが非常に悪かったことがわかります。そのため、人々は独自のJWTパーサーを作成することに慣れました。Spring Security 5が登場したとき、Springは構成して使用できるjwtフィルターを組み込みで実装しました。しかし、古いSpring Securityチュートリアルがたくさんあり、何よりも公式ドキュメントを読んでいない開発者がたくさんいます。

彼らは主にグーグルのチュートリアルをして、間違った情報を取得して、それに取り組んでいます。

しかし、簡単に説明できます。

SecurityContextRepositoryセッションベースの認証（サーバーがクライアントとのセッションを確立する）がある場合、リクエスト中にSecurityContext（セッション）をThreadLocalに保存します。ただし、リクエストが終了するとすぐに、どこかに保存しない限り、セッションは失われます。はSecurityContextPersistenceFilterを使用しSecurityContextRepositoryてThreadLocalからセッションを抽出して保存します。最も一般的なのは、セッションをHttpSessionに保存することです。

AuthenticationManagerカスタム認証プロセスを実行する場合は、これをオーバーライドします。何かを検証したい場合の例、カスタムLDAP、データベースなどを呼び出します。ここで認証を実行します。ただし、ほとんどの標準ログイン（ldap、sql-servers、基本ログインなど）.httpBasic()には、事前に実装されたAuthenticationManagerを取得するようなログインタイプを選択すると、事前に構築された構成可能なマネージャーが既に実装されていることに注意してください。

UserDetailsManagerカスタムUserDetailsオブジェクト（通常はプリンシパルとも呼ばれます）を作成する場合は、これをオーバーライドします。UserDetailsManagerで、データベースを検索してユーザーをフェッチしてから、UserDetailsオブジェクトをビルドして返します。

これらの2つのインターフェースは、最も通常のカスタム実装であり、基本認証/セッションベースの認証が必要な場合に使用されます。

トークンをやりたい場合は、トークンの発行者は誰ですか？通常、発行者は個別であり、すべてのサービスはトークンを取得して発行者に対して検証するだけです。

これがいくつかの質問を説明することを願っています。私はこれをバスに書いたので、おそらくいくつかのことが間違っていて、100％正しくないなどです。