ログインに Google の OAuth 2.0 認証システムを使用するには、Google API Console でプロジェクトを設定して OAuth 2.0 認証情報を取得する必要があります。

	メモ
	認証用の Google の OAuth 2.0 の実装 (英語) は OpenID Connect 1.0 (英語) 仕様に準拠しており、OpenID 認定 (英語) です。

「OAuth 2.0 のセットアップ」セクションから始まる OpenID Connect (英語) ページの指示に従ってください。

「OAuth 2.0 資格情報の取得」の手順を完了すると、クライアント ID とクライアントシークレットで構成される資格情報を持つ新しい OAuth クライアントが必要になります。

リダイレクト URI は、エンドユーザーのユーザーエージェントが Google で認証 され、同意ページで OAuth クライアント （前の手順で作成された） へのアクセスを許可した後にリダイレクトされるアプリケーション内のパスです。

「リダイレクト URI の設定」サブセクションで、 承認されたリダイレクト URI フィールドが  http://localhost:8080/login/oauth2/code/google に設定されていることを確認します。

	ヒント
	デフォルトのリダイレクト URI テンプレートは  {baseUrl}/login/oauth2/code/{registrationId} です。 registrationId は ClientRegistration の一意の識別子です。

	重要
	OAuth クライアントがプロキシサーバーの背後で実行されている場合は、プロキシサーバー構成をチェックして、アプリケーションが正しく構成されていることを確認することをお勧めします。また、 redirect-uri でサポートされている URI テンプレート変数も参照してください。

Google で新しい OAuth クライアントを作成したため、 認証フローに OAuth クライアントを使用するようにアプリケーションを構成する必要があります。そうするには:

Spring Boot 2.x サンプルを起動し、 http://localhost:8080 に移動します。次に、Google へのリンクを表示するデフォルトの 自動生成されたログインページにリダイレクトされます。

Google リンクをクリックすると、認証のために Google にリダイレクトされます。

Google アカウントの認証情報で認証した後、表示される次のページは同意画面です。同意画面では、以前に作成した OAuth クライアントへのアクセスを認可または拒否するように求められます。 許可するをクリックして、OAuth クライアントがメールアドレスと基本的なプロファイル情報にアクセスすることを認可します。

この時点で、OAuth クライアントは UserInfo エンドポイント (英語) からメールアドレスと基本プロファイル情報を取得し、認証済みセッションを確立します。

次の例は、 ClientRegistrationRepository @Bean を登録する方法を示しています。

@Configuration
public class OAuth2LoginConfig {

    @Bean
    public ClientRegistrationRepository clientRegistrationRepository() {
        return new InMemoryClientRegistrationRepository(this.googleClientRegistration());
    }

    private ClientRegistration googleClientRegistration() {
        return ClientRegistration.withRegistrationId("google")
            .clientId("google-client-id")
            .clientSecret("google-client-secret")
            .clientAuthenticationMethod(ClientAuthenticationMethod.BASIC)
            .authorizationGrantType(AuthorizationGrantType.AUTHORIZATION_CODE)
            .redirectUriTemplate("{baseUrl}/login/oauth2/code/{registrationId}")
            .scope("openid", "profile", "email", "address", "phone")
            .authorizationUri("https://accounts.google.com/o/oauth2/v2/auth")
            .tokenUri("https://www.googleapis.com/oauth2/v4/token")
            .userInfoUri("https://www.googleapis.com/oauth2/v3/userinfo")
            .userNameAttributeName(IdTokenClaimNames.SUB)
            .jwkSetUri("https://www.googleapis.com/oauth2/v3/certs")
            .clientName("Google")
            .build();
    }
}

次の例は、 WebSecurityConfigurerAdapter に  @EnableWebSecurity を提供し、 httpSecurity.oauth2Login() を介して OAuth 2.0 ログインを有効にする方法を示しています。

@EnableWebSecurity
public class OAuth2LoginSecurityConfig extends WebSecurityConfigurerAdapter {

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
            .authorizeRequests(authorizeRequests ->
                authorizeRequests
                    .anyRequest().authenticated()
            )
            .oauth2Login(withDefaults());
    }
}

次の例は、 ClientRegistrationRepository @Bean を登録し、 WebSecurityConfigurerAdapter を提供することにより、自動構成を完全にオーバーライドする方法を示しています。

@Configuration
public class OAuth2LoginConfig {

    @EnableWebSecurity
    public static class OAuth2LoginSecurityConfig extends WebSecurityConfigurerAdapter {

        @Override
        protected void configure(HttpSecurity http) throws Exception {
            http
                .authorizeRequests(authorizeRequests ->
                    authorizeRequests
                        .anyRequest().authenticated()
                )
                .oauth2Login(withDefaults());
        }
    }

    @Bean
    public ClientRegistrationRepository clientRegistrationRepository() {
        return new InMemoryClientRegistrationRepository(this.googleClientRegistration());
    }

    private ClientRegistration googleClientRegistration() {
        return ClientRegistration.withRegistrationId("google")
            .clientId("google-client-id")
            .clientSecret("google-client-secret")
            .clientAuthenticationMethod(ClientAuthenticationMethod.BASIC)
            .authorizationGrantType(AuthorizationGrantType.AUTHORIZATION_CODE)
            .redirectUriTemplate("{baseUrl}/login/oauth2/code/{registrationId}")
            .scope("openid", "profile", "email", "address", "phone")
            .authorizationUri("https://accounts.google.com/o/oauth2/v2/auth")
            .tokenUri("https://www.googleapis.com/oauth2/v4/token")
            .userInfoUri("https://www.googleapis.com/oauth2/v3/userinfo")
            .userNameAttributeName(IdTokenClaimNames.SUB)
            .jwkSetUri("https://www.googleapis.com/oauth2/v3/certs")
            .clientName("Google")
            .build();
    }
}

デフォルトでは、OAuth 2.0 ログインページは  DefaultLoginPageGeneratingFilter によって自動生成されます。デフォルトのログインページには、設定された各 OAuth クライアントとその  ClientRegistration.clientName がリンクとして表示され、認可リクエスト（または OAuth 2.0 ログイン）を開始できます。

	メモ
	DefaultLoginPageGeneratingFilter が構成済みの OAuth クライアントのリンクを表示するには、登録された  ClientRegistrationRepository が  Iterable<ClientRegistration> も実装する必要があります。参考のために  InMemoryClientRegistrationRepository を参照してください。

各 OAuth クライアントのリンクの宛先は、デフォルトで次のようになります。

OAuth2AuthorizationRequestRedirectFilter.DEFAULT_AUTHORIZATION_REQUEST_BASE_URI + "/{registrationId}"

次の行に例を示します。

<a href="/oauth2/authorization/google">Google</a>

デフォルトのログインページをオーバーライドするには、 oauth2Login().loginPage() および（オプションで）  oauth2Login().authorizationEndpoint().baseUri() を構成します。

次のリストに例を示します。

@EnableWebSecurity
public class OAuth2LoginSecurityConfig extends WebSecurityConfigurerAdapter {

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
            .oauth2Login(oauth2Login ->
                oauth2Login
                    .loginPage("/login/oauth2")
                    ...
                    .authorizationEndpoint(authorizationEndpoint ->
                        authorizationEndpoint
                            .baseUri("/login/oauth2/authorization")
                            ...
                    )
            );
    }
}

	重要
	カスタムログインページを表示できる  @RequestMapping("/login/oauth2") を備えた  @Controller を提供する必要があります。

	ヒント
	前述のように、 oauth2Login().authorizationEndpoint().baseUri() の構成はオプションです。ただし、カスタマイズする場合は、各 OAuth クライアントへのリンクが  authorizationEndpoint().baseUri() と一致することを確認してください。 次の行に例を示します。 <a href="/login/oauth2/authorization/google">Google</a>

リダイレクトエンドポイントは、認可サーバーがリソース所有者ユーザーエージェントを介してクライアントに認可レスポンス（認可資格情報を含む）を返すために使用されます。

	ヒント
	OAuth 2.0 Login は認証コード付与を活用します。認証情報は認証コードです。

デフォルトの Authorization Response  baseUri （リダイレクトエンドポイント）は  /login/oauth2/code/* であり、 OAuth2LoginAuthenticationFilter.DEFAULT_FILTER_PROCESSES_URI で定義されています。

Authorization Response  baseUri をカスタマイズする場合は、次の例に示すように構成します。

@EnableWebSecurity
public class OAuth2LoginSecurityConfig extends WebSecurityConfigurerAdapter {

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
            .oauth2Login(oauth2Login ->
                oauth2Login
                    .redirectionEndpoint(redirectionEndpoint ->
                        redirectionEndpoint
                            .baseUri("/login/oauth2/callback/*")
                            ...
                    )
            );
    }
}

	重要
	また、 ClientRegistration.redirectUriTemplate がカスタム Authorization Response  baseUri と一致することを確認する必要があります。 次のリストに例を示します。 return CommonOAuth2Provider.GOOGLE.getBuilder("google") .clientId("google-client-id") .clientSecret("google-client-secret") .redirectUriTemplate("{baseUrl}/login/oauth2/callback/{registrationId}") .build();

UserInfo エンドポイントには、次のサブセクションで説明するように、いくつかの構成オプションが含まれています。

ユーザー権限のマッピング

ユーザーが OAuth 2.0 プロバイダーで正常に認証された後、 OAuth2User.getAuthorities() （または  OidcUser.getAuthorities()）が新しいセットの  GrantedAuthority インスタンスにマッピングされ、認証の補完時に  OAuth2AuthenticationToken に提供されます。

	ヒント
	OAuth2AuthenticationToken.getAuthorities() は、 hasRole('USER') や  hasRole('ADMIN') などでリクエストを認可するために使用されます。

ユーザー権限をマッピングするときに選択できるオプションがいくつかあります。

• GrantedAuthoritiesMapper を使用する
• OAuth2UserService を使用した委譲ベースの戦略

GrantedAuthoritiesMapper を使用する

GrantedAuthoritiesMapper の実装を提供し、次の例に示すように構成します。

@EnableWebSecurity
public class OAuth2LoginSecurityConfig extends WebSecurityConfigurerAdapter {

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
            .oauth2Login(oauth2Login ->
                oauth2Login
                    .userInfoEndpoint(userInfoEndpoint ->
                        userInfoEndpoint
                            .userAuthoritiesMapper(this.userAuthoritiesMapper())
                            ...
                    )
            );
    }

    private GrantedAuthoritiesMapper userAuthoritiesMapper() {
        return (authorities) -> {
            Set<GrantedAuthority> mappedAuthorities = new HashSet<>();

            authorities.forEach(authority -> {
                if (OidcUserAuthority.class.isInstance(authority)) {
                    OidcUserAuthority oidcUserAuthority = (OidcUserAuthority)authority;

                    OidcIdToken idToken = oidcUserAuthority.getIdToken();
                    OidcUserInfo userInfo = oidcUserAuthority.getUserInfo();

                    // Map the claims found in idToken and/or userInfo
                    // to one or more GrantedAuthority's and add it to mappedAuthorities

                } else if (OAuth2UserAuthority.class.isInstance(authority)) {
                    OAuth2UserAuthority oauth2UserAuthority = (OAuth2UserAuthority)authority;

                    Map<String, Object> userAttributes = oauth2UserAuthority.getAttributes();

                    // Map the attributes found in userAttributes
                    // to one or more GrantedAuthority's and add it to mappedAuthorities

                }
            });

            return mappedAuthorities;
        };
    }
}

または、次の例に示すように、 GrantedAuthoritiesMapper @Bean を登録して、構成に自動的に適用することもできます。

@EnableWebSecurity
public class OAuth2LoginSecurityConfig extends WebSecurityConfigurerAdapter {

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
            .oauth2Login(withDefaults());
    }

    @Bean
    public GrantedAuthoritiesMapper userAuthoritiesMapper() {
        ...
    }
}

OAuth2UserService を使用した委譲ベースの戦略

この戦略は  GrantedAuthoritiesMapper を使用するよりも高度ですが、 OAuth2UserRequest および  OAuth2User （OAuth 2.0 UserService を使用する場合）または  OidcUserRequest および  OidcUser （OpenID Connect 1.0 UserService を使用する場合）にアクセスできるため、より柔軟です。

OAuth2UserRequest （および  OidcUserRequest）は、関連する  OAuth2AccessToken へのアクセスを提供します。これは、ユーザーのカスタム権限をマップする前に、 委譲者が保護リソースから権限情報をフェッチする必要がある場合に非常に便利です。

次の例は、OpenID Connect 1.0 UserService を使用して、委譲ベースの戦略を実装および構成する方法を示しています。

@EnableWebSecurity
public class OAuth2LoginSecurityConfig extends WebSecurityConfigurerAdapter {

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
            .oauth2Login(oauth2Login ->
                oauth2Login
                    .userInfoEndpoint(userInfoEndpoint ->
                        userInfoEndpoint
                            .oidcUserService(this.oidcUserService())
                            ...
                    )
            );
    }

    private OAuth2UserService<OidcUserRequest, OidcUser> oidcUserService() {
        final OidcUserService delegate = new OidcUserService();

        return (userRequest) -> {
            // Delegate to the default implementation for loading a user
            OidcUser oidcUser = delegate.loadUser(userRequest);

            OAuth2AccessToken accessToken = userRequest.getAccessToken();
            Set<GrantedAuthority> mappedAuthorities = new HashSet<>();

            // TODO
            // 1) Fetch the authority information from the protected resource using accessToken
            // 2) Map the authority information to one or more GrantedAuthority's and add it to mappedAuthorities

            // 3) Create a copy of oidcUser but use the mappedAuthorities instead
            oidcUser = new DefaultOidcUser(mappedAuthorities, oidcUser.getIdToken(), oidcUser.getUserInfo());

            return oidcUser;
        };
    }
}

カスタム OAuth2User の構成

CustomUserTypesOAuth2UserService は、カスタム  OAuth2User タイプのサポートを提供する  OAuth2UserService の実装です。

デフォルトの実装（ DefaultOAuth2User）がニーズに合わない場合は、 OAuth2User の独自の実装を定義できます。

次のコードは、GitHub のカスタム  OAuth2User タイプを登録する方法を示しています。

@EnableWebSecurity
public class OAuth2LoginSecurityConfig extends WebSecurityConfigurerAdapter {

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
            .oauth2Login(oauth2Login ->
                oauth2Login
                    .userInfoEndpoint(userInfoEndpoint ->
                        userInfoEndpoint
                            .customUserType(GitHubOAuth2User.class, "github")
                            ...
                    )
            );
    }
}

次のコードは、GitHub のカスタム  OAuth2User タイプの例を示しています。

public class GitHubOAuth2User implements OAuth2User {
    private List<GrantedAuthority> authorities =
        AuthorityUtils.createAuthorityList("ROLE_USER");
    private Map<String, Object> attributes;
    private String id;
    private String name;
    private String login;
    private String email;

    @Override
    public Collection<? extends GrantedAuthority> getAuthorities() {
        return this.authorities;
    }

    @Override
    public Map<String, Object> getAttributes() {
        if (this.attributes == null) {
            this.attributes = new HashMap<>();
            this.attributes.put("id", this.getId());
            this.attributes.put("name", this.getName());
            this.attributes.put("login", this.getLogin());
            this.attributes.put("email", this.getEmail());
        }
        return attributes;
    }

    public String getId() {
        return this.id;
    }

    public void setId(String id) {
        this.id = id;
    }

    @Override
    public String getName() {
        return this.name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public String getLogin() {
        return this.login;
    }

    public void setLogin(String login) {
        this.login = login;
    }

    public String getEmail() {
        return this.email;
    }

    public void setEmail(String email) {
        this.email = email;
    }
}

	ヒント
	id、 name、 login、 email は、GitHub の UserInfo レスポンスで返される属性です。UserInfo エンドポイントから返される詳細情報については、「認証されたユーザーを取得する」 (英語) の API ドキュメントを参照してください。

OAuth 2.0 UserService

DefaultOAuth2UserService は、標準の OAuth 2.0 プロバイダーをサポートする  OAuth2UserService の実装です。

	メモ
	OAuth2UserService は、エンドユーザー（リソース所有者）のユーザー属性を UserInfo エンドポイントから取得し（認可フロー中にクライアントに付与されたアクセストークンを使用して）、 AuthenticatedPrincipal を  OAuth2User の形式で返します。

DefaultOAuth2UserService は、UserInfo エンドポイントでユーザー属性をリクエストするときに  RestOperations を使用します。

UserInfo リクエストの前処理をカスタマイズする必要がある場合は、 DefaultOAuth2UserService.setRequestEntityConverter() にカスタム  Converter<OAuth2UserRequest, RequestEntity<?>> を提供できます。デフォルトの実装  OAuth2UserRequestEntityConverter は、デフォルトで  Authorization ヘッダーに  OAuth2AccessToken を設定する UserInfo リクエストの  RequestEntity 表現を構築します。

一方、UserInfo レスポンスのリアクティブ処理をカスタマイズする必要がある場合は、 DefaultOAuth2UserService.setRestOperations() にカスタム構成の  RestOperations を提供する必要があります。デフォルトの  RestOperations は次のように構成されています。

RestTemplate restTemplate = new RestTemplate();
restTemplate.setErrorHandler(new OAuth2ErrorResponseErrorHandler());

OAuth2ErrorResponseErrorHandler は、OAuth 2.0 エラー（400 間違ったリクエスト）を処理できる  ResponseErrorHandler です。OAuth 2.0 Error パラメーターを  OAuth2Error に変換するために  OAuth2ErrorHttpMessageConverter を使用します。

DefaultOAuth2UserService をカスタマイズする場合でも、 OAuth2UserService の独自の実装を提供する場合でも、次の例に示すように構成する必要があります。

@EnableWebSecurity
public class OAuth2LoginSecurityConfig extends WebSecurityConfigurerAdapter {

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
            .oauth2Login(oauth2Login ->
                oauth2Login
                    .userInfoEndpoint(userInfoEndpoint ->
                        userInfoEndpoint
                            .userService(this.oauth2UserService())
                            ...
                    )
            );
    }

    private OAuth2UserService<OAuth2UserRequest, OAuth2User> oauth2UserService() {
        ...
    }
}

@EnableWebSecurity
public class OAuth2LoginSecurityConfig extends WebSecurityConfigurerAdapter {

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
            .oauth2Login(oauth2Login ->
                oauth2Login
                    .userInfoEndpoint(userInfoEndpoint ->
                        userInfoEndpoint
                            .oidcUserService(this.oidcUserService())
                            ...
                    )
            );
    }

    private OAuth2UserService<OidcUserRequest, OidcUser> oidcUserService() {
        ...
    }
}

OpenID Connect 1.0 認証は ID トークン (英語) を導入します。ID トークン (英語) は、クライアントが使用する場合の認可サーバーによるエンドユーザーの認証に関するクレームを含むセキュリティトークンです。

ID トークンは JSON Web トークン (英語) （JWT）として表され、JSON Web 署名 (英語) （JWS）を使用して署名する必要があります。

OidcIdTokenDecoderFactory は、 OidcIdToken 署名検証に使用される  JwtDecoder を提供します。デフォルトのアルゴリズムは  RS256 ですが、クライアントの登録時に割り当てられる場合は異なる場合があります。これらの場合、特定のクライアントに割り当てられた予想される JWS アルゴリズムを返すようにリゾルバーを構成できます。

JWS アルゴリズムリゾルバーは、 ClientRegistration を受け入れ、クライアントに期待される  JwsAlgorithm を返す  Function です。 SignatureAlgorithm.RS256 または  MacAlgorithm.HS256

次のコードは、すべての  ClientRegistration に対してデフォルトで  MacAlgorithm.HS256 になるように  OidcIdTokenDecoderFactory @Bean を構成する方法を示しています。

@Bean
public JwtDecoderFactory<ClientRegistration> idTokenDecoderFactory() {
    OidcIdTokenDecoderFactory idTokenDecoderFactory = new OidcIdTokenDecoderFactory();
    idTokenDecoderFactory.setJwsAlgorithmResolver(clientRegistration -> MacAlgorithm.HS256);
    return idTokenDecoderFactory;
}

	メモ
	HS256、 HS384 または  HS512 などの MAC ベースのアルゴリズムの場合、 client-id に対応する  client-secret が署名検証の対称キーとして使用されます。

	ヒント
	OpenID Connect 1.0 認証用に複数の  ClientRegistration が構成されている場合、JWS アルゴリズムリゾルバーは提供された  ClientRegistration を評価して、返すアルゴリズムを決定します。

OpenID Connect セッション管理 1.0 では、クライアントを使用してプロバイダーのエンドユーザーをログアウトできます。利用可能な戦略の 1 つは RP からのログアウト (英語) です。

OpenID プロバイダーがセッション管理とディスカバリ (英語) の両方をサポートしている場合、クライアントは OpenID プロバイダーのディスカバリメタデータ (英語) から  end_session_endpoint URL を取得できます。これは、次の例のように、 issuer-uri を使用して  ClientRegistration を構成することで実現できます。

spring:
  security:
    oauth2:
      client:
        registration:
          okta:
            client-id: okta-client-id
            client-secret: okta-client-secret
            ...
        provider:
          okta:
            issuer-uri: https://dev-1234.oktapreview.com

…および RP 開始ログアウトを実装する  OidcClientInitiatedLogoutSuccessHandler は、次のように構成できます。

@EnableWebSecurity
public class OAuth2LoginSecurityConfig extends WebSecurityConfigurerAdapter {

    @Autowired
    private ClientRegistrationRepository clientRegistrationRepository;

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
            .authorizeRequests(authorizeRequests ->
                authorizeRequests
                    .anyRequest().authenticated()
            )
            .oauth2Login(withDefaults())
            .logout(logout ->
                logout
                    .logoutSuccessHandler(oidcLogoutSuccessHandler())
            );
    }

    private LogoutSuccessHandler oidcLogoutSuccessHandler() {
        OidcClientInitiatedLogoutSuccessHandler oidcLogoutSuccessHandler =
                new OidcClientInitiatedLogoutSuccessHandler(this.clientRegistrationRepository);

        // Sets the `URI` that the End-User's User Agent will be redirected to
        // after the logout has been performed at the Provider
        oidcLogoutSuccessHandler.setPostLogoutRedirectUri(URI.create("https://localhost:8080"));

        return oidcLogoutSuccessHandler;
    }
}

ClientRegistration は、OAuth 2.0 または OpenID Connect 1.0 プロバイダーに登録されたクライアントの表現です。

クライアント登録には、クライアント ID、クライアントシークレット、認可付与タイプ、リダイレクト URI、スコープ、認可 URI、トークン URI、その他の詳細などの情報が保持されます。

ClientRegistration とそのプロパティは次のように定義されています。

public final class ClientRegistration {
    private String registrationId;  
    private String clientId;    
    private String clientSecret;    
    private ClientAuthenticationMethod clientAuthenticationMethod;  
    private AuthorizationGrantType authorizationGrantType;  
    private String redirectUriTemplate; 
    private Set<String> scopes; 
    private ProviderDetails providerDetails;
    private String clientName;  

    public class ProviderDetails {
        private String authorizationUri;    
        private String tokenUri;    
        private UserInfoEndpoint userInfoEndpoint;
        private String jwkSetUri;   
        private Map<String, Object> configurationMetadata;  

        public class UserInfoEndpoint {
            private String uri; 
            private AuthenticationMethod authenticationMethod;  
            private String userNameAttributeName;   

        }
    }
}

ClientRegistration は、OpenID Connect プロバイダーの構成エンドポイント (英語) または認可サーバーのメタデータエンドポイント (英語) の検出を使用して最初に構成できます。

ClientRegistrations は、次の例に見られるように、このメソッドで  ClientRegistration を構成するための便利なメソッドを提供します。

ClientRegistration clientRegistration =
    ClientRegistrations.fromIssuerLocation("https://idp.example.com/issuer").build();

上記のコードは、シリーズ  https://idp.example.com/issuer/.well-known/openid-configuration (英語) 、次に  https://idp.example.com/.well-known/openid-configuration/issuer (英語) 、最後に  https://idp.example.com/.well-known/oauth-authorization-server/issuer (英語) で照会し、最初に停止して 200 レスポンスを返します。

別の方法として、 ClientRegistrations.fromOidcIssuerLocation() を使用して、OpenID Connect プロバイダーの構成エンドポイントのみを照会できます。

ClientRegistrationRepository は、OAuth 2.0/OpenID Connect 1.0  ClientRegistration（s）のリポジトリとして機能します。

	メモ
	クライアント登録情報は最終的に保存され、関連する認可サーバーによって所有されます。このリポジトリは、認可サーバーに保存されているプライマリクライアント登録情報のサブセットを取得する機能を提供します。

Spring Boot 2.x 自動構成は、 spring.security.oauth2.client.registration. [registrationId] の各プロパティを  ClientRegistration のインスタンスにバインドし、 ClientRegistrationRepository 内の各  ClientRegistration インスタンスを構成します。

	メモ
	ClientRegistrationRepository のデフォルトの実装は  InMemoryClientRegistrationRepository です。

また、自動構成は、 ClientRegistrationRepository を  ApplicationContext の  @Bean として登録し、アプリケーションで必要な場合に依存関係の注入に使用できるようにします。

次のリストに例を示します。

@Controller
public class OAuth2ClientController {

    @Autowired
    private ClientRegistrationRepository clientRegistrationRepository;

    @GetMapping("/")
    public String index() {
        ClientRegistration oktaRegistration =
            this.clientRegistrationRepository.findByRegistrationId("okta");

        ...

        return "index";
    }
}

OAuth2AuthorizedClient は、認可クライアントの表現です。エンドユーザー（リソース所有者）がクライアントに保護されたリソースにアクセスする認可を与えた場合、クライアントは認可されたと見なされます。

OAuth2AuthorizedClient は、 OAuth2AccessToken （およびオプションの  OAuth2RefreshToken）を、認可を認可した  Principal エンドユーザーである  ClientRegistration （クライアント）およびリソース所有者に関連付ける目的に役立ちます。

OAuth2AuthorizedClientRepository は、Web リクエスト間で  OAuth2AuthorizedClient を保持するロールを果たします。一方、 OAuth2AuthorizedClientService の主なロールは、アプリケーションレベルで  OAuth2AuthorizedClient を管理することです。

開発者の観点から、 OAuth2AuthorizedClientRepository または  OAuth2AuthorizedClientService は、クライアントに関連付けられた  OAuth2AccessToken をルックアップする機能を提供し、保護されたリソースリクエストを開始するために使用できるようにします。

次のリストに例を示します。

@Controller
public class OAuth2ClientController {

    @Autowired
    private OAuth2AuthorizedClientService authorizedClientService;

    @GetMapping("/")
    public String index(Authentication authentication) {
        OAuth2AuthorizedClient authorizedClient =
            this.authorizedClientService.loadAuthorizedClient("okta", authentication.getName());

        OAuth2AccessToken accessToken = authorizedClient.getAccessToken();

        ...

        return "index";
    }
}

	メモ
	Spring Boot 2.x 自動構成は、 OAuth2AuthorizedClientRepository および / または  OAuth2AuthorizedClientService @Bean を  ApplicationContext に登録します。ただし、アプリケーションは、カスタム  OAuth2AuthorizedClientRepository または  OAuth2AuthorizedClientService @Bean をオーバーライドして登録することを選択できます。

OAuth2AuthorizedClientManager は、 OAuth2AuthorizedClient の全体的な管理を担当します。

主な責任は次のとおりです。

OAuth2AuthorizedClientProvider は、OAuth 2.0 クライアントを認可（または再認可）するための戦略を実装します。実装は通常、認可付与タイプを実装します。 authorization_code、 client_credentials など。

OAuth2AuthorizedClientManager のデフォルトの実装は  DefaultOAuth2AuthorizedClientManager です。これは、委譲ベースの複合を使用して複数の認可付与タイプをサポートする可能性のある  OAuth2AuthorizedClientProvider に関連付けられています。 OAuth2AuthorizedClientProviderBuilder を使用して、委譲ベースのコンポジットを構成および構築できます。

次のコードは、 authorization_code、 refresh_token、 client_credentials、 password 認可付与タイプのサポートを提供する  OAuth2AuthorizedClientProvider コンポジットを構成および構築する方法の例を示しています。

@Bean
public OAuth2AuthorizedClientManager authorizedClientManager(
        ClientRegistrationRepository clientRegistrationRepository,
        OAuth2AuthorizedClientRepository authorizedClientRepository) {

    OAuth2AuthorizedClientProvider authorizedClientProvider =
            OAuth2AuthorizedClientProviderBuilder.builder()
                    .authorizationCode()
                    .refreshToken()
                    .clientCredentials()
                    .password()
                    .build();

    DefaultOAuth2AuthorizedClientManager authorizedClientManager =
            new DefaultOAuth2AuthorizedClientManager(
                    clientRegistrationRepository, authorizedClientRepository);
    authorizedClientManager.setAuthorizedClientProvider(authorizedClientProvider);

    return authorizedClientManager;
}

DefaultOAuth2AuthorizedClientManager は、タイプ  Function<OAuth2AuthorizeRequest, Map<String, Object>> の  contextAttributesMapper にも関連付けられます。 Function<OAuth2AuthorizeRequest, Map<String, Object>> は、 OAuth2AuthorizeRequest から  OAuth2AuthorizationContext に関連付けられる属性の  Map への属性のマッピングを担当します。これは、 OAuth2AuthorizedClientProvider に必要な（サポートされている）属性を指定する必要がある場合に役立ちます。 PasswordOAuth2AuthorizedClientProvider では、リソース所有者の  username および  password が  OAuth2AuthorizationContext.getAttributes() で使用可能である必要があります。

次のコードは、 contextAttributesMapper の例を示しています。

@Bean
public OAuth2AuthorizedClientManager authorizedClientManager(
        ClientRegistrationRepository clientRegistrationRepository,
        OAuth2AuthorizedClientRepository authorizedClientRepository) {

    OAuth2AuthorizedClientProvider authorizedClientProvider =
            OAuth2AuthorizedClientProviderBuilder.builder()
                    .password()
                    .refreshToken()
                    .build();

    DefaultOAuth2AuthorizedClientManager authorizedClientManager =
            new DefaultOAuth2AuthorizedClientManager(
                    clientRegistrationRepository, authorizedClientRepository);
    authorizedClientManager.setAuthorizedClientProvider(authorizedClientProvider);

    // Assuming the `username` and `password` are supplied as `HttpServletRequest` parameters,
    // map the `HttpServletRequest` parameters to `OAuth2AuthorizationContext.getAttributes()`
    authorizedClientManager.setContextAttributesMapper(contextAttributesMapper());

    return authorizedClientManager;
}

private Function<OAuth2AuthorizeRequest, Map<String, Object>> contextAttributesMapper() {
    return authorizeRequest -> {
        Map<String, Object> contextAttributes = Collections.emptyMap();
        HttpServletRequest servletRequest = authorizeRequest.getAttribute(HttpServletRequest.class.getName());
        String username = servletRequest.getParameter(OAuth2ParameterNames.USERNAME);
        String password = servletRequest.getParameter(OAuth2ParameterNames.PASSWORD);
        if (StringUtils.hasText(username) && StringUtils.hasText(password)) {
            contextAttributes = new HashMap<>();

            // `PasswordOAuth2AuthorizedClientProvider` requires both attributes
            contextAttributes.put(OAuth2AuthorizationContext.USERNAME_ATTRIBUTE_NAME, username);
            contextAttributes.put(OAuth2AuthorizationContext.PASSWORD_ATTRIBUTE_NAME, password);
        }
        return contextAttributes;
    };
}

DefaultOAuth2AuthorizedClientManager は、 HttpServletRequest のコンテキストで 以内にを使用するように設計されています。 HttpServletRequest コンテキストの 外側を操作する場合は、代わりに  AuthorizedClientServiceOAuth2AuthorizedClientManager を使用してください。

サービスアプリケーションは、 AuthorizedClientServiceOAuth2AuthorizedClientManager を使用する場合の一般的な使用例です。多くの場合、サービスアプリケーションはユーザーの操作なしでバックグラウンドで実行され、通常はユーザーアカウントではなくシステムレベルのアカウントで実行されます。 client_credentials 付与タイプで構成された OAuth 2.0 クライアントは、サービスアプリケーションのタイプと見なすことができます。

次のコードは、 client_credentials 付与タイプのサポートを提供する  AuthorizedClientServiceOAuth2AuthorizedClientManager を構成する方法の例を示しています。

@Bean
public OAuth2AuthorizedClientManager authorizedClientManager(
        ClientRegistrationRepository clientRegistrationRepository,
        OAuth2AuthorizedClientService authorizedClientService) {

    OAuth2AuthorizedClientProvider authorizedClientProvider =
            OAuth2AuthorizedClientProviderBuilder.builder()
                    .clientCredentials()
                    .build();

    AuthorizedClientServiceOAuth2AuthorizedClientManager authorizedClientManager =
            new AuthorizedClientServiceOAuth2AuthorizedClientManager(
                    clientRegistrationRepository, authorizedClientService);
    authorizedClientManager.setAuthorizedClientProvider(authorizedClientProvider);

    return authorizedClientManager;
}

@RegisteredOAuth2AuthorizedClient アノテーションは、メソッドパラメーターをタイプ  OAuth2AuthorizedClient の引数値に解決する機能を提供します。これは、 OAuth2AuthorizedClientManager または  OAuth2AuthorizedClientService を使用して  OAuth2AuthorizedClient にアクセスするのに比べて、便利な代替手段です。

@Controller
public class OAuth2ClientController {

    @GetMapping("/")
    public String index(@RegisteredOAuth2AuthorizedClient("okta") OAuth2AuthorizedClient authorizedClient) {
        OAuth2AccessToken accessToken = authorizedClient.getAccessToken();

        ...

        return "index";
    }
}

@RegisteredOAuth2AuthorizedClient アノテーションは  OAuth2AuthorizedClientArgumentResolver によって処理されます。 OAuth2AuthorizedClientArgumentResolver は OAuth2AuthorizedClientManager を直接使用するため、その機能を継承します。

ServletOAuth2AuthorizedClientExchangeFilterFunction は、 ClientRequest.attributes() （リクエスト属性）から  OAuth2AuthorizedClient を解決することにより、（リクエストに）使用するクライアントを決定します。

次のコードは、 OAuth2AuthorizedClient をリクエスト属性として設定する方法を示しています。

@GetMapping("/")
public String index(@RegisteredOAuth2AuthorizedClient("okta") OAuth2AuthorizedClient authorizedClient) {
    String resourceUri = ...

    String body = webClient
            .get()
            .uri(resourceUri)
            .attributes(oauth2AuthorizedClient(authorizedClient))   
            .retrieve()
            .bodyToMono(String.class)
            .block();

    ...

    return "index";
}

次のコードは、 ClientRegistration.getRegistrationId() をリクエスト属性として設定する方法を示しています。

@GetMapping("/")
public String index() {
    String resourceUri = ...

    String body = webClient
            .get()
            .uri(resourceUri)
            .attributes(clientRegistrationId("okta"))   
            .retrieve()
            .bodyToMono(String.class)
            .block();

    ...

    return "index";
}

OAuth2AuthorizedClient または  ClientRegistration.getRegistrationId() のいずれもリクエスト属性として提供されない場合、 ServletOAuth2AuthorizedClientExchangeFilterFunction はその構成に応じて、使用する デフォルトのクライアントを決定できます。

setDefaultOAuth2AuthorizedClient(true) が構成され、ユーザーが  HttpSecurity.oauth2Login() を使用して認証した場合、現在の  OAuth2AuthenticationToken に関連付けられた  OAuth2AccessToken が使用されます。

次のコードは、特定の構成を示しています。

@Bean
WebClient webClient(OAuth2AuthorizedClientManager authorizedClientManager) {
    ServletOAuth2AuthorizedClientExchangeFilterFunction oauth2Client =
            new ServletOAuth2AuthorizedClientExchangeFilterFunction(authorizedClientManager);
    oauth2Client.setDefaultOAuth2AuthorizedClient(true);
    return WebClient.builder()
            .apply(oauth2Client.oauth2Configuration())
            .build();
}

	警告
	すべての HTTP リクエストはアクセストークンを受け取るため、この機能には注意が必要です。

あるいは、 setDefaultClientRegistrationId("okta") が有効な  ClientRegistration で構成されている場合、 OAuth2AuthorizedClient に関連付けられた  OAuth2AccessToken が使用されます。

次のコードは、特定の構成を示しています。

@Bean
WebClient webClient(OAuth2AuthorizedClientManager authorizedClientManager) {
    ServletOAuth2AuthorizedClientExchangeFilterFunction oauth2Client =
            new ServletOAuth2AuthorizedClientExchangeFilterFunction(authorizedClientManager);
    oauth2Client.setDefaultClientRegistrationId("okta");
    return WebClient.builder()
            .apply(oauth2Client.oauth2Configuration())
            .build();
}

	警告
	すべての HTTP リクエストはアクセストークンを受け取るため、この機能には注意が必要です。

Spring Boot アプリケーションで、使用する認可サーバーを指定するには、次のようにします。

spring:
  security:
    oauth2:
      resourceserver:
        jwt:
          issuer-uri: https://idp.example.com/issuer

ここで、 https://idp.example.com/issuer (英語)  は、認可サーバーが発行する JWT トークンの  iss クレームに含まれる値です。リソースサーバーは、このプロパティを使用して、さらに自己構成を行い、認可サーバーの公開キーを検出し、受信 JWT を検証します。

	メモ
	issuer-uri プロパティを使用するには、 https://idp.example.com/issuer/.well-known/openid-configuration (英語) 、 https://idp.example.com/.well-known/openid-configuration/issuer (英語) 、または  https://idp.example.com/.well-known/oauth-authorization-server/issuer (英語)  のいずれかが認可サーバーでサポートされているエンドポイントであることも真である必要があります。このエンドポイントは、プロバイダー構成 (英語) エンドポイントまたは認可サーバーのメタデータ (英語) エンドポイントと呼ばれます。

以上です！

このプロパティとこれらの依存関係を使用すると、Resource Server は自動的に JWT エンコードされたベアラートークンを検証するように自身を構成します。

これは、決定論的な起動プロセスを通じてこれを実現します。

このプロセスの結果、リソースサーバーが正常に起動するには、認可サーバーが起動してリクエストを受信する必要があります。

	メモ
	リソースサーバーがクエリを実行したときに認可サーバーがダウンした場合（適切なタイムアウトが与えられた場合）、起動は失敗します。

アプリケーションが起動すると、Resource Server は  Authorization: Bearer ヘッダーを含むリクエストの処理を試みます。

GET / HTTP/1.1
Authorization: Bearer some-token-value # Resource Server will process this

このスキームが示されている限り、Resource Server は Bearer Token 仕様に従ってリクエストの処理を試みます。

整形式の JWT が与えられると、リソースサーバーは次のことを行います。

	メモ
	認可サーバーが新しい鍵を使用できるようになると、Spring Security は JWT の検証に使用される鍵を自動的にローテーションします。

デフォルトでは、結果の  Authentication#getPrincipal は Spring Security  Jwt オブジェクトであり、 Authentication#getName は JWT の  sub プロパティ（存在する場合）にマップします。

ここから、次へのジャンプを検討してください。

リソースサーバーの起動を認可サーバーの可用性に結び付けずに構成する方法

Spring Boot なしで構成する方法

認可サーバーの JWK Set Uri は 、構成プロパティとして構成することも、DSL で提供することもできます。

@EnableWebSecurity
public class DirectlyConfiguredJwkSetUri extends WebSecurityConfigurerAdapter {
    protected void configure(HttpSecurity http) {
        http
            .authorizeRequests()
                .anyRequest().authenticated()
                .and()
            .oauth2ResourceServer()
                .jwt()
                    .jwkSetUri("https://idp.example.com/.well-known/jwks.json");
    }
}

jwkSetUri() の使用は、構成プロパティよりも優先されます。

jwkSetUri() よりも強力なのは  decoder() です。これは、 JwtDecoder の Boot 自動構成を完全に置き換えます。

@EnableWebSecurity
public class DirectlyConfiguredJwtDecoder extends WebSecurityConfigurerAdapter {
    protected void configure(HttpSecurity http) {
        http
            .authorizeRequests()
                .anyRequest().authenticated()
                .and()
            .oauth2ResourceServer()
                .jwt()
                    .decoder(myCustomDecoder());
    }
}

これは、 validation 、 mapping 、または request timeouts の ようなより詳細な構成が必要な場合に便利です。

または、 JwtDecoder を公開すると @Bean は  decoder() と同じ効果があります。

@Bean
public JwtDecoder jwtDecoder() {
    return NimbusJwtDecoder.withJwkSetUri(jwkSetUri).build();
}

アルゴリズムを設定する最も簡単な方法は、プロパティとしてです:

spring:
  security:
    oauth2:
      resourceserver:
        jwt:
          jws-algorithm: RS512
          jwk-set-uri: https://idp.example.org/.well-known/jwks.json

ただし、より強力にするには、 NimbusJwtDecoder に同梱されているビルダーを使用できます。

@Bean
JwtDecoder jwtDecoder() {
    return NimbusJwtDecoder.fromJwkSetUri(this.jwkSetUri)
            .jwsAlgorithm(RS512).build();
}

jwsAlgorithm を複数回呼び出すと、 NimbusJwtDecoder は次のように複数のアルゴリズムを信頼するように構成されます。

@Bean
JwtDecoder jwtDecoder() {
    return NimbusJwtDecoder.fromJwkSetUri(this.jwkSetUri)
            .jwsAlgorithm(RS512).jwsAlgorithm(EC512).build();
}

または、 jwsAlgorithms を呼び出すことができます。

@Bean
JwtDecoder jwtDecoder() {
    return NimbusJwtDecoder.fromJwkSetUri(this.jwkSetUri)
            .jwsAlgorithms(algorithms -> {
                    algorithms.add(RS512);
                    algorithms.add(EC512);
            }).build();
}

Spring Security の JWT サポートは Nimbus に基づいているため、その優れた機能もすべて使用できます。

例: Nimbus には、JWK Set URI レスポンスに基づいてアルゴリズムのセットを選択する  JWSKeySelector 実装があります。これを使用して、 NimbusJwtDecoder を次のように生成できます。

@Bean
public JwtDecoder jwtDecoder() {
    // makes a request to the JWK Set endpoint
    JWSKeySelector<SecurityContext> jwsKeySelector =
            JWSAlgorithmFamilyJWSKeySelector.fromJWKSetURL(this.jwkSetUrl);

    DefaultJWTProcessor<SecurityContext> jwtProcessor =
            new DefaultJWTProcessor<>();
    jwtProcessor.setJWSKeySelector(jwsKeySelector);

    return new NimbusJwtDecoder(jwtProcessor);
}

Spring Boot を介したキーの指定は非常に簡単です。キーの場所は次のように指定できます。

spring:
  security:
    oauth2:
      resourceserver:
        jwt:
          public-key-location: classpath:my-key.pub

または、より洗練されたルックアップを可能にするために、 RsaKeyConversionServicePostProcessor を後処理できます。

@Bean
BeanFactoryPostProcessor conversionServiceCustomizer() {
    return beanFactory ->
        beanFactory.getBean(RsaKeyConversionServicePostProcessor.class)
                .setResourceLoader(new CustomResourceLoader());
}

キーの場所を指定します。

key.location: hfds://my-key.pub

そして、値をオートワイヤーします。

@Value("${key.location}")
RSAPublicKey key;

RSAPublicKey を直接接続するには、次のように適切な  NimbusJwtDecoder ビルダーを使用するだけです。

@Bean
public JwtDecoder jwtDecoder() {
    return NimbusJwtDecoder.withPublicKey(this.key).build();
}

ただし、このデフォルトでは不十分な状況がいくつかあります。例: 一部の認可サーバーは  scope 属性を使用せず、独自のカスタム属性を持っています。または、リソースサーバーは、属性または属性の構成を内部化された機関に適合させる必要がある場合もあります。

このために、DSL は  jwtAuthenticationConverter() を公開します:

@EnableWebSecurity
public class DirectlyConfiguredJwkSetUri extends WebSecurityConfigurerAdapter {
    protected void configure(HttpSecurity http) {
        http
            .authorizeRequests()
                .anyRequest().authenticated()
                .and()
            .oauth2ResourceServer()
                .jwt()
                    .jwtAuthenticationConverter(grantedAuthoritiesExtractor());
    }
}

Converter<Jwt, AbstractAuthenticationToken> grantedAuthoritiesExtractor() {
    JwtAuthenticationConverter jwtAuthenticationConverter =
            new JwtAuthenticationConverter();

    jwtAuthenticationConverter.setJwtGrantedAuthoritiesConverter
            (new GrantedAuthoritiesExtractor());

    return jwtAuthenticationConverter;
}

Jwt を  Authentication に変換する責任があります。その構成の一部として、 Jwt から付与された権限の  Collection に移行する補助コンバーターを提供できます。

その最終的なコンバーターは、以下の  GrantedAuthoritiesExtractor のようなものです。

static class GrantedAuthoritiesExtractor
        implements Converter<Jwt, Collection<GrantedAuthority>> {

    public Collection<GrantedAuthority> convert(Jwt jwt) {
        Collection<String> authorities = (Collection<String>)
                jwt.getClaims().get("mycustomclaim");

        return authorities.stream()
                .map(SimpleGrantedAuthority::new)
                .collect(Collectors.toList());
    }
}

柔軟性を高めるため、DSL はコンバーターを  Converter<Jwt, AbstractAuthenticationToken> を実装するクラスに完全に置き換えることをサポートしています。

static class CustomAuthenticationConverter implements Converter<Jwt, AbstractAuthenticationToken> {
    public AbstractAuthenticationToken convert(Jwt jwt) {
        return new CustomAuthenticationToken(jwt);
    }
}

通常、JWT には有効期間があり、ウィンドウの開始は  nbf クレームで示され、終了は  exp クレームで示されます。

ただし、すべてのサーバーでクロックドリフトが発生する可能性があります。これにより、あるサーバーではトークンが期限切れになり、別のサーバーでは期限切れになります。これにより、分散システムでコラボレーションサーバーの数が増えると、実装の胸焼けが発生する可能性があります。

リソースサーバーは  JwtTimestampValidator を使用してトークンの有効期間を検証し、 clockSkew で構成して上記の問題を軽減できます。

@Bean
JwtDecoder jwtDecoder() {
     NimbusJwtDecoder jwtDecoder = (NimbusJwtDecoder)
             JwtDecoders.fromIssuerLocation(issuerUri);

     OAuth2TokenValidator<Jwt> withClockSkew = new DelegatingOAuth2TokenValidator<>(
            new JwtTimestampValidator(Duration.ofSeconds(60)),
            new IssuerValidator(issuerUri));

     jwtDecoder.setJwtValidator(withClockSkew);

     return jwtDecoder;
}

	メモ
	デフォルトでは、Resource Server は 30 秒のクロックスキューを設定します。

aud クレームのチェックの追加は、 OAuth2TokenValidator API を使用すると簡単です。

public class AudienceValidator implements OAuth2TokenValidator<Jwt> {
    OAuth2Error error = new OAuth2Error("invalid_token", "The required audience is missing", null);

    public OAuth2TokenValidatorResult validate(Jwt jwt) {
        if (jwt.getAudience().contains("messaging")) {
            return OAuth2TokenValidatorResult.success();
        } else {
            return OAuth2TokenValidatorResult.failure(error);
        }
    }
}

次に、リソースサーバーに追加するには、 JwtDecoder インスタンスを指定するだけです。

@Bean
JwtDecoder jwtDecoder() {
    NimbusJwtDecoder jwtDecoder = (NimbusJwtDecoder)
        JwtDecoders.fromIssuerLocation(issuerUri);

    OAuth2TokenValidator<Jwt> audienceValidator = new AudienceValidator();
    OAuth2TokenValidator<Jwt> withIssuer = JwtValidators.createDefaultWithIssuer(issuerUri);
    OAuth2TokenValidator<Jwt> withAudience = new DelegatingOAuth2TokenValidator<>(withIssuer, audienceValidator);

    jwtDecoder.setJwtValidator(withAudience);

    return jwtDecoder;
}

デフォルトでは、 MappedJwtClaimSetConverter はクレームを次のタイプに強制しようとします。

MappedJwtClaimSetConverter.withDefaults を使用して、個々の申し立ての変換戦略を構成できます。

@Bean
JwtDecoder jwtDecoder() {
    NimbusJwtDecoder jwtDecoder = NimbusJwtDecoder.withJwkSetUri(jwkSetUri).build();

    MappedJwtClaimSetConverter converter = MappedJwtClaimSetConverter
            .withDefaults(Collections.singletonMap("sub", this::lookupUserIdBySub));
    jwtDecoder.setClaimSetConverter(converter);

    return jwtDecoder;
}

これにより、 sub のデフォルトクレームコンバーターがオーバーライドされることを除き、すべてのデフォルトが保持されます。

MappedJwtClaimSetConverter は、たとえば既存のシステムに適応するために、カスタムクレームを追加するためにも使用できます。

MappedJwtClaimSetConverter.withDefaults(Collections.singletonMap("custom", custom -> "value"));

また、同じ API を使用して、クレームを削除することも簡単です。

MappedJwtClaimSetConverter.withDefaults(Collections.singletonMap("legacyclaim", legacy -> null));

一度に複数のクレームを参照したり、クレームの名前を変更したりするような、より洗練されたシナリオでは、Resource Server は  Converter<Map<String, Object>, Map<String,Object>> を実装するクラスを受け入れます。

public class UsernameSubClaimAdapter implements Converter<Map<String, Object>, Map<String, Object>> {
    private final MappedJwtClaimSetConverter delegate =
            MappedJwtClaimSetConverter.withDefaults(Collections.emptyMap());

    public Map<String, Object> convert(Map<String, Object> claims) {
        Map<String, Object> convertedClaims = this.delegate.convert(claims);

        String username = (String) convertedClaims.get("user_name");
        convertedClaims.put("sub", username);

        return convertedClaims;
    }
}

そして、インスタンスは通常のように提供できます:

@Bean
JwtDecoder jwtDecoder() {
    NimbusJwtDecoder jwtDecoder = NimbusJwtDecoder.withJwkSetUri(jwkSetUri).build();
    jwtDecoder.setClaimSetConverter(new UsernameSubClaimAdapter());
    return jwtDecoder;
}

イントロスペクションエンドポイントの場所を指定するには、次のようにします。

security:
  oauth2:
    resourceserver:
      opaque-token:
        introspection-uri: https://idp.example.com/introspect
        client-id: client
        client-secret: secret

ここで、 https://idp.example.com/introspect (英語)  は認証サーバーによってホストされるイントロスペクションエンドポイントであり、 client-id および  client-secret はそのエンドポイントをヒットするために必要な資格情報です。

リソースサーバーはこれらのプロパティを使用して、さらに自己構成し、受信 JWT を検証します。

	メモ
	イントロスペクションを使用する場合、認可サーバーの言葉は法律です。認可サーバーがトークンが有効であるとレスポンスした場合、有効です。

以上です！

このプロパティとこれらの依存関係が使用されると、リソースサーバーは自動的に不透明なベアラートークンを検証するように構成します。

この起動プロセスは、エンドポイントを検出する必要がなく、追加の検証ルールが追加されないため、JWT よりもかなり単純です。

アプリケーションが起動すると、Resource Server は  Authorization: Bearer ヘッダーを含むリクエストの処理を試みます。

GET / HTTP/1.1
Authorization: Bearer some-token-value # Resource Server will process this

このスキームが示されている限り、Resource Server は Bearer Token 仕様に従ってリクエストの処理を試みます。

Opaque トークンを指定すると、リソースサーバーは

結果として得られる  Authentication#getPrincipal は、デフォルトでは Spring Security  OAuth2AuthenticatedPrincipal (Javadoc)  オブジェクトであり、 Authentication#getName はトークンの  sub プロパティ（存在する場合）にマップします。

ここから、次の場所にジャンプできます。

もちろん、これは、SpEL を介して属性にアクセスできることも意味します。

例:  @PreAuthorize アノテーションを使用できるように  @EnableGlobalMethodSecurity を使用する場合、次のことができます。

@PreAuthorize("principal?.attributes['sub'] == 'foo'")
public String forFoosEyesOnly() {
    return "foo";
}

認可サーバーの Introspection Uri は 、構成プロパティとして構成するか、DSL で提供できます。

@EnableWebSecurity
public class DirectlyConfiguredIntrospectionUri extends WebSecurityConfigurerAdapter {
    protected void configure(HttpSecurity http) {
        http
            .authorizeRequests()
                .anyRequest().authenticated()
                .and()
            .oauth2ResourceServer()
                .opaqueToken()
                    .introspectionUri("https://idp.example.com/introspect")
                    .introspectionClientCredentials("client", "secret");
    }
}

introspectionUri() の使用は、構成プロパティよりも優先されます。

introspectionUri() よりも強力なのは  introspector() です。これは、 OpaqueTokenIntrospector の Boot 自動構成を完全に置き換えます。

@EnableWebSecurity
public class DirectlyConfiguredIntrospector extends WebSecurityConfigurerAdapter {
    protected void configure(HttpSecurity http) {
        http
            .authorizeRequests()
                .anyRequest().authenticated()
                .and()
            .oauth2ResourceServer()
                .opaqueToken()
                    .introspector(myCustomIntrospector());
    }
}

これは、権限マッピング、JWT の取り消し、またはリクエストタイムアウトなどのより深い構成が必要な場合に便利です。

または、 OpaqueTokenIntrospector を公開すると @Bean は  introspector() と同じ効果があります。

@Bean
public OpaqueTokenIntrospector introspector() {
    return new NimbusOpaqueTokenIntrospector(introspectionUri, clientId, clientSecret);
}

デフォルトでは、Opaque トークンサポートは、イントロスペクションレスポンスからスコープ要求を抽出し、個々の  GrantedAuthority インスタンスに解析します。

例: イントロスペクションのレスポンスが次の場合:

{
    "active" : true,
    "scope" : "message:read message:write"
}

次に、Resource Server は、 message:read 用と  message:write 用の 2 つの権限を持つ  Authentication を生成します。

これはもちろん、属性セットを見て独自の方法で変換するカスタム  OpaqueTokenIntrospector を使用してカスタマイズできます。

public class CustomAuthoritiesOpaqueTokenIntrospector implements OpaqueTokenIntrospector {
    private OpaqueTokenIntrospector delegate =
            new NimbusOpaqueTokenIntrospector("https://idp.example.org/introspect", "client", "secret");

    public OAuth2AuthenticatedPrincipal introspect(String token) {
        OAuth2AuthenticatedPrincipal principal = this.delegate.introspect(token);
        return new DefaultOAuth2AuthenticatedPrincipal(
                principal.getName(), principal.getAttributes(), extractAuthorities(principal));
    }

    private Collection<GrantedAuthority> extractAuthorities(OAuth2AuthenticatedPrincipal principal) {
        List<String> scopes = principal.getAttribute(OAuth2IntrospectionClaimNames.SCOPE);
        return scopes.stream()
                .map(SimpleGrantedAuthority::new)
                .collect(Collectors.toList());
    }
}

その後、このカスタムイントロスペクターは、 @Bean として公開するだけで構成できます。

@Bean
public OpaqueTokenIntrospector introspector() {
    return new CustomAuthoritiesOpaqueTokenIntrospector();
}

リクエストマテリアルによるテナントの解決は、次のように、実行時に  AuthenticationManager を決定する  AuthenticationManagerResolver を実装することで実行できます。

@Component
public class TenantAuthenticationManagerResolver
        implements AuthenticationManagerResolver<HttpServletRequest> {
    private final BearerTokenResolver resolver = new DefaultBearerTokenResolver();
    private final TenantRepository tenants; 

    private final Map<String, AuthenticationManager> authenticationManagers = new ConcurrentHashMap<>(); 

    public TenantAuthenticationManagerResolver(TenantRepository tenants) {
        this.tenants = tenants;
    }

    @Override
    public AuthenticationManager resolve(HttpServletRequest request) {
        return this.authenticationManagers.computeIfAbsent(toTenant(request), this::fromTenant);
    }

    private String toTenant(HttpServletRequest request) {
        String[] pathParts = request.getRequestURI().split("/");
        return pathParts.length > 0 ? pathParts[1] : null;
    }

    private AuthenticationManager fromTenant(String tenant) {
        return Optional.ofNullable(this.tenants.get(tenant)) 
                .map(JwtDecoders::fromIssuerLocation) 
                .map(JwtAuthenticationProvider::new)
                .orElseThrow(() -> new IllegalArgumentException("unknown tenant"))::authenticate;
    }
}

そして、DSL でこの  AuthenticationManagerResolver を指定します。

http
    .authorizeRequests()
        .anyRequest().authenticated()
        .and()
    .oauth2ResourceServer()
        .authenticationManagerResolver(this.tenantAuthenticationManagerResolver);

クレームによるテナントの解決は、リクエスト資料による解決と同様です。唯一の本当の違いは、 toTenant メソッドの実装です。

@Component
public class TenantAuthenticationManagerResolver implements AuthenticationManagerResolver<HttpServletRequest> {
    private final BearerTokenResolver resolver = new DefaultBearerTokenResolver();
    private final TenantRepository tenants; 

    private final Map<String, AuthenticationManager> authenticationManagers = new ConcurrentHashMap<>(); 

    public TenantAuthenticationManagerResolver(TenantRepository tenants) {
        this.tenants = tenants;
    }

    @Override
    public AuthenticationManager resolve(HttpServletRequest request) {
        return this.authenticationManagers.computeIfAbsent(toTenant(request), this::fromTenant); 
    }

    private String toTenant(HttpServletRequest request) {
        try {
            String token = this.resolver.resolve(request);
            return (String) JWTParser.parse(token).getJWTClaimsSet().getIssuer();
        } catch (Exception e) {
            throw new IllegalArgumentException(e);
        }
    }

    private AuthenticationManager fromTenant(String tenant) {
        return Optional.ofNullable(this.tenants.get(tenant)) 
                .map(JwtDecoders::fromIssuerLocation) 
                .map(JwtAuthenticationProvider::new)
                .orElseThrow(() -> new IllegalArgumentException("unknown tenant"))::authenticate;
    }
}

http
    .authorizeRequests()
        .anyRequest().authenticated()
        .and()
    .oauth2ResourceServer()
        .authenticationManagerResolver(this.tenantAuthenticationManagerResolver);

この戦略は単純ですが、JWT が  AuthenticationManagerResolver によって一度解析され、次に  JwtDecoder によって再び解析されるというトレードオフが伴うことに気づいたかもしれません。

Nimbus の  JWTClaimSetAwareJWSKeySelector を使用して  JwtDecoder を直接設定することにより、この余分な解析を軽減できます。

@Component
public class TenantJWSKeySelector
    implements JWTClaimSetAwareJWSKeySelector<SecurityContext> {

    private final TenantRepository tenants; 
    private final Map<String, JWSKeySelector<SecurityContext>> selectors = new ConcurrentHashMap<>(); 

    public TenantJWSKeySelector(TenantRepository tenants) {
        this.tenants = tenants;
    }

    @Override
    public List<? extends Key> selectKeys(JWSHeader jwsHeader, JWTClaimsSet jwtClaimsSet, SecurityContext securityContext)
            throws KeySourceException {
        return this.selectors.computeIfAbsent(toTenant(jwtClaimsSet), this::fromTenant)
                .selectJWSKeys(jwsHeader, securityContext);
    }

    private String toTenant(JWTClaimsSet claimSet) {
        return (String) claimSet.getClaim("iss");
    }

    private JWSKeySelector<SecurityContext> fromTenant(String tenant) {
        return Optional.ofNullable(this.tenantRepository.findById(tenant)) 
                .map(t -> t.getAttrbute("jwks_uri"))
                .map(this::fromUri)
                .orElseThrow(() -> new IllegalArgumentException("unknown tenant"));
    }

    private JWSKeySelector<SecurityContext> fromUri(String uri) {
        try {
            return JWSAlgorithmFamilyJWSKeySelector.fromJWKSetURL(new URL(uri)); 
        } catch (Exception e) {
            throw new IllegalArgumentException(e);
        }
    }
}

上記のキーセレクターは、多くのキーセレクターの構成です。JWT の  iss クレームに基づいて、使用するキーセレクターを選択します。

	メモ
	このアプローチを使用するには、トークンの署名の一部としてクレームセットを含めるように認可サーバーが構成されていることを確認してください。これがなければ、発行者が悪役によって改ざんされていないという保証はありません。

次に、 JWTProcessor を作成できます。

@Bean
JWTProcessor jwtProcessor(JWTClaimSetJWSKeySelector keySelector) {
    ConfigurableJWTProcessor<SecurityContext> jwtProcessor =
            new DefaultJWTProcessor();
    jwtProcessor.setJWTClaimSetJWSKeySelector(keySelector);
    return jwtProcessor;
}

すでに見たように、テナント認識をこのレベルに下げるためのトレードオフは、より多くの構成です。もう少しあります。

次に、発行者を検証していることを確認します。ただし、発行者は JWT ごとに異なる可能性があるため、テナント対応バリデーターも必要になります。

@Component
public class TenantJwtIssuerValidator implements OAuth2TokenValidator<Jwt> {
    private final TenantRepository tenants;
    private final Map<String, JwtIssuerValidator> validators = new ConcurrentHashMap<>();

    public TenantJwtIssuerValidator(TenantRepository tenants) {
        this.tenants = tenants;
    }

    @Override
    public OAuth2TokenValidatorResult validate(Jwt token) {
        return this.validators.computeIfAbsent(toTenant(token), this::fromTenant)
                .validate(token);
    }

    private String toTenant(Jwt jwt) {
        return jwt.getIssuer();
    }

    private JwtIssuerValidator fromTenant(String tenant) {
        return Optional.ofNullable(this.tenants.findById(tenant))
                .map(t -> t.getAttribute("issuer"))
                .map(JwtIssuerValidator::new)
                .orElseThrow(() -> new IllegalArgumentException("unknown tenant"));
    }
}

テナント対応プロセッサーとテナント対応バリデーターができたため、 JwtDecoder の作成に進むことができます:

@Bean
JwtDecoder jwtDecoder(JWTProcessor jwtProcessor, OAuth2TokenValidator<Jwt> jwtValidator) {
    NimbusJwtDecoder decoder = new NimbusJwtDecoder(processor);
    OAuth2TokenValidator<Jwt> validator = new DelegatingOAuth2TokenValidator<>
            (JwtValidators.createDefault(), this.jwtValidator);
    decoder.setJwtValidator(validator);
    return decoder;
}

テナントの解決についてお話ししました。

リクエストマテリアルによってテナントを解決することを選択した場合は、同じメソッドでダウンストリームリソースサーバーに対処する必要があります。例: サブドメインで解決する場合、同じサブドメインを使用してダウンストリームリソースサーバーをアドレス指定する必要があります。

ただし、ベアラートークンの要求によって解決する場合は、Spring Security のベアラートークン伝播のサポートについて学習してください。

例: カスタムヘッダーからベアラートークンを読み取る必要がある場合があります。これを実現するために、次の例に示すように、 HeaderBearerTokenResolver インスタンスを DSL に接続できます。

http
    .oauth2ResourceServer()
        .bearerTokenResolver(new HeaderBearerTokenResolver("x-goog-iap-jwt-assertion"));

または、以下に示すように、 DefaultBearerTokenResolver を構成することで実行できるフォームパラメーターからトークンを読み取ることもできます。

DefaultBearerTokenResolver resolver = new DefaultBearerTokenResolver();
resolver.setAllowFormEncodedBodyParameter(true);
http
    .oauth2ResourceServer()
        .bearerTokenResolver(resolver);

現時点では  RestTemplate の専用サポートはありませんが、独自のインターセプターを使用して非常に簡単に伝播を実現できます。

@Bean
RestTemplate rest() {
    RestTemplate rest = new RestTemplate();
    rest.getInterceptors().add((request, body, execution) -> {
        Authentication authentication = SecurityContextHolder.getContext().getAuthentication();
        if (authentication == null) {
            return execution.execute(request, body);
        }

        if (!(authentication.getCredentials() instanceof AbstractOAuth2Token)) {
            return execution.execute(request, body);
        }

        AbstractOAuth2Token token = (AbstractOAuth2Token) authentication.getCredentials();
        request.getHeaders().setBearerAuth(token.getTokenValue());
        return execution.execute(request, body);
    });
    return rest;
}