最新の安定バージョンについては、Spring Security 6.3.1 を使用してください! |
OAuth 2.0 リソースサーバー
Spring Security は、2 つの形式の OAuth 2.0 ベアラートークン [IETF] (英語) を使用したエンドポイントの保護をサポートしています。
Opaque トークン
これは、アプリケーションが権限管理を認可サーバー [IETF] (英語) (Okta や Ping Identity など)に委譲している場合に便利です。この認可サーバーは、リソースサーバーがリクエストを認可するために調べることができます。
このセクションでは、Spring Security が OAuth 2.0 ベアラートークン [IETF] (英語) をどのようにサポートするかについて詳しく説明します。
JWT [GitHub] (英語) と Opaque トークン [GitHub] (英語) の両方の作業サンプルが Spring Security サンプルリポジトリ [GitHub] (英語) で利用可能です。 |
Spring Security 内で Bearer Token Authentication がどのように機能するかを見てみましょう。まず、基本認証と同様に、WWW 認証 [IETF] (英語) ヘッダーが認証されていないクライアントに返送されることがわかります。
上の図は、SecurityFilterChain
ダイアグラムを基にしています。
最初に、ユーザーが認可されていないリソース /private
に対して認証されていないリクエストを行います。
Spring Security の FilterSecurityInterceptor
は、認証されていないリクエストが AccessDeniedException
をスローすることによって拒否されたことを示します。
ユーザーが認証されていないため、ExceptionTranslationFilter
は Start Authentication を開始します。構成された AuthenticationEntryPoint
は、WWW-Authenticate ヘッダーを送信する BearerTokenAuthenticationEntryPoint
(Javadoc) のインスタンスです。RequestCache
は通常、クライアントが最初にリクエストしたリクエストを再生できるため、リクエストを保存しない NullRequestCache
です。
クライアントは WWW-Authenticate: Bearer
ヘッダーを受信すると、ベアラートークンで再試行する必要があることを認識します。以下は、処理される無記名トークンのフローです。
この図は、SecurityFilterChain
ダイアグラムから構築されています。
ユーザーがベアラートークンを送信すると、BearerTokenAuthenticationFilter
は HttpServletRequest
からトークンを抽出して Authentication
の一種である BearerTokenAuthenticationToken
を作成します。
次に、HttpServletRequest
が AuthenticationManagerResolver
に渡され、AuthenticationManagerResolver
が AuthenticationManager
を選択します。BearerTokenAuthenticationToken
は、認証のために AuthenticationManager
に渡されます。AuthenticationManager
がどのように見えるかの詳細は、JWT または Opaque トークンのどちら用に構成されているかによって異なります。
認証に失敗した場合、Failure
SecurityContextHolder はクリアされます。
AuthenticationEntryPoint
が呼び出され、WWW-Authenticate ヘッダーが再度送信されるようトリガーします。
認証が成功した場合は、Success .
認証は SecurityContextHolder に設定されます。
BearerTokenAuthenticationFilter
はFilterChain.doFilter(request,response)
を呼び出して、残りのアプリケーションロジックを続行します。