Spring Security Is the oauth2login really using the accesstoken in a secure way?

In OAuth2LoginReactiveAuthenticationManager the following is stated in the comments.

This {@link org.springframework.security.authentication.AuthenticationProvider} is responsible for authenticating an Authorization Code credential with the Authorization Server's Token Endpoint and if valid, exchanging it for an Access Token credential.

Then in the DefaultReactiveOAuth2UserService we use the content of the accesstoken when creating our session. However unlike the documentation about the resourceserver option in spring security i can find no information if the signing and claims have been validated in the access token when used to create sessions using oauth2login.

OAuth2AccessToken token = userRequest.getAccessToken();
for (String scope : token.getScopes()) {
    authorities.add(new SimpleGrantedAuthority("SCOPE_" + scope));
}

What is the reason there are no signing check for the accesstoken when using oauth2login or where in the code is it validated? What is the easiest way for me to add accesstoken validation if my usecase requires that?

Comment From: jgrandja

@henrik-larsson-15-wcar OAuth 2.0 Clients do not validate access tokens, only Resource Servers validate tokens. The access token is opaque to the client and it only uses it to call a protected resource. The Resource Server will validate (authorize) the access token and allow it to proceed or deny.

Take a look at Section 1.4 Access Token:

Access tokens are credentials used to access protected resources. An access token is a string representing an authorization issued to the client. The string is usually opaque to the client.

However, when an OAuth 2.0 Client participates in an OpenID Connect flow, it is responsible for validating the ID Token as part of the authentication process. This is handled by OidcIdTokenValidator.

Just a heads up that questions should be asked on StackOverflow. GitHub issues are meant for reporting bugs and requesting new features or enhancements.

Comment From: henrik-larsson-15-wcar

Yes but you are using the scopes from the access token to secure the endpoints in your service since scopes are translated into GrantedAuthority. In my mind that is you use data from an unverified access token to secure your API, sure you might not call it a resource server but the issue is still there?

Comment From: jgrandja

@henrik-larsson-15-wcar The logic you reference in the comment is correct. There is no issue there.

If the user consented (granted) the requested scope(s) and completes a successful authentication, we can safely assign the scope(s) requested by the client as the default SimpleGrantedAuthority represented as a SCOPE_* authority.