CODEWITHSUNDEEP
oauthspring-securityoauth-2.0spring-security-oauth2
jamesbond007
jamesbond007

Reputation: 598

Why do Spring Security OAuth2 DefaultTokenServices check clientId on loading the Authentication?

Why do the DefaultTokenServices check the clientId in the method loadAuthentication:

    if (clientDetailsService != null) {
        String clientId = result.getOAuth2Request().getClientId();
        try {
            clientDetailsService.loadClientByClientId(clientId);
        }
        catch (ClientRegistrationException e) {
            throw new InvalidTokenException("Client not valid: " + clientId, e);
        }
    }

The above is the question, the following is only some background to explain why I came up with it. The reason for me to ask is a special scenario: The check poses problems for example in Spring Boot Applications that are a Resource Server and an Authorization Server at the same time, if the Authorization Server is not reponsible for all clients, but the Resource Server must serve all clients.

On a pure Resource Server, the clientDetailsService can be null. The Resource Server can work without knowing the registered clients, while security can still be enforced on other properties of access tokens, such as the resource ID and the validity of the access token.

On a pure Authorization Server, there is no problem, because the Authorization Server must have a clientDetailsService that knows all clients for which tokens can be issued.

On a mixed server however, the Authorization Server may not know all possible clients, because there might exist other Authorization Servers. The Resource Server components would then check every clientId within the above code, with a denial for all requests that stem from clients that this Authorization Server does not know about.

Example to make the scenario understandable:

  1. There is a mixed server (Authorization and Resource Server in one) that issues tokens for business users and that offers services to administer business users (e.g. create, lock, unlock, etc.).

  2. There is also a separate authorization server that issues tokens for administrative users. The administrative users use a UI to administer (e.g. create, lock, unlock etc.) business users, i.e. they use services of 1. with tokens issued by 2.

Upvotes: 2

Views: 1741

Answers (1)

Dave Syer
Dave Syer

Reputation: 58124

I guess I don't really follow the logic that makes it necessary to segregate the clients. In any case I don't think it's mandatory for the resource server and authorization endpoints to share the same *TokenServices (they don't even use the same interface).

Upvotes: 0

Related Questions