Spring OAuth2 ResourceServer dependency hell

Question

I want to implement a resource server (Spring Boot Rest Backend and secured via OAuth2 with JWT).

I get a resource server running which processes JWT tokens from Keycloak Authentication Server. But there are still gaps in my knowledge how to verify JWT tokens.

A deeper look at the Spring reference documentation opens the Hellmouth.

In the Spring OAuth2 Boot Reference there is a link to a feature matrix. This matrix lists the following spring options for implementing a resource server.

• Spring Security OAuth (2.2.+)
• Spring Security (5.1.+)
• Spring Cloud Security (1.2.+)
• Spring Boot OAuth2 (1.5.x)

But now I have found the following dependency

• 'org.springframework.security.oauth.boot:spring-security-oauth2-autoconfigure:2.1.6.RELEASE'

Which Spring Project or Starter does this dependency refer to? Is the matrix outdated? And if so, where can I find a current overview of the selection of a suitable solution for implementing a resource server?

It's all very opaque, can anyone bring some light into this darkness?

Answer 1

Which Spring Project or Starter does this dependency refer to? Is the matrix outdated?

The reference you link to, and the spring-security-oauth2-autoconfigure dependency, are for OAuth projects that are now in maintenance mode. As the feature matrix mentions, Spring Security 5 is meant to replace all the previous OAuth projects that were being developed separately. However, Spring Security 5 still doesn't offer support for creating an authorization server, so it's not quite there yet. But since you're implementing a resource server, Spring Security 5 is definitely the way to go.

And if so, where can I find a current overview of the selection of a suitable solution for implementing a resource server?

Check out the Spring Security 5 documentation for detailed information on how to implement a resource server.

Tip #1: As was mentioned, there are a ton of tutorials for the "outdated" Spring Security OAuth project. Whenever you see the @EnableResourceServer annotation, you'll know it's the old way of doing things.

This is the "Spring Security 5 way": http.oauth2ResourceServer().

Tip#2: If you're using Spring Boot, you'll need the following dependencies:

    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-security</artifactId>
    </dependency>

    <dependency>
        <groupId>org.springframework.security</groupId>
        <artifactId>spring-security-oauth2-resource-server</artifactId>
    </dependency>

    <dependency>
        <groupId>org.springframework.security</groupId>
        <artifactId>spring-security-oauth2-jose</artifactId>
    </dependency>

Why? Well you need the starter to use Spring Security 5. And the docs explain why you need the last 2:

Most Resource Server support is collected into spring-security-oauth2-resource-server. However, the support for decoding and verifying JWTs is in spring-security-oauth2-jose, meaning that both are necessary in order to have a working resource server that supports JWT-encoded Bearer Tokens.

Answer 2

JWT is a RFC standard (RFC 7519) standard just like OAuth 2.0 (RFC 6749) which is used to represent claims between two parties.

Lets go one by one.

1. In OAuth 2.0, a token is generated which can be used to access protected resources present on a resource server.
2. This default token which is generated is generally a random string which has no information present in it and the resource server needs to verify the token with the authorization server for every hit that you make using the authorization server behind the scenes
3. To get the user information (if required) including his authorities, role, name etc., the resource server will have to ask the authorization server by passing the token to a specified URL as the token in itself is a random string
4. Now you may ask, "Don't you think there will be a substantial delay with every request I make to the resource server if it has to verify my token for every request that I make with the Authorization Server". The answer is Yes! There will be. That's where JWT comes in.
5. Using JWT, we can embed all the information that might be required by the resource server inside the token string itself. So now, that random token string becomes a encoded (not encrypted or hashed) string which can be easily decoded by the resource server without any interaction with the authorization server
6. That part is fine. But how do the resource server know whether the JWT payload information is not being tempered with. After all, I can change my authorities in the JWT to elevate the access. This is where the signature part of JWT comes in.
7. The signature part contains a pre-shared key or could be a public key, if the JWT is created using a asymmetric key pair which basically verifies that the payload information has not been tempered with

Coming to your question now

But an important note first. Spring Community is in process of a unprecedented change in the spring security project which is a re-write of the whole project. See this video for more info. So your confusion is not unusual. There are many examples on the web which takes into consideration the old way of implementing OAuth flow with Spring.

On the resource server side, you will need a converter which will convert your JWT into actual payload and you have to provide the signature key to this converter so that it can verify that the JWT is a valid one.

About the dependencies, I have successfully implemented two separate modules for authorization server and resource server using spring boot and here are the dependencies I have used on both sides are just two

org.springframework.boot:spring-boot-starter-security org.springframework.security.oauth.boot:spring-security-oauth2-autoconfigure

So your dependency hell tree will look like

• Spring Security (5.1.+)
• org.springframework.security.oauth.boot:spring-security-oauth2-autoconfigure

Not that of a hell after all ;)