How-to: In the same microservice supports jdbc token checking.

[zxuanhong]

Expected Behavior

1. In the same microservice. It should be possible to verify the token directly to the same microservice resource server instead of accessing the authorization server through http
2. Imagine that the service is supposed to be trusted. But once a service interface is accessed, the authorization service is invoked for authentication. This puts a lot of pressure on the authorization server.
3. I hope I can get some answers. Because a microservice system services trust each other.

[sjohnr]

Hi @zxiaozhou! Just to clarify, are you asking (for a how-to guide that demonstrates) how to use opaque tokens (not JWTs) that can be verified via a JDBC connection on a resource server? Something like this?

                                  ┌─────┐
                                  │     │
                     ┌───────────►│ DB  │◄─────────────┐
                     │            │     │              │
                     │            └─────┘              │
                     │                                 │
                     │                                 │
                     │                                 │
┌────────────────────┴────┐                     ┌──────┴──────────────────┐
│                         │                     │                         │
│                         │                     │                         │
│                         │                     │                         │
│ Authz Server            │                     │  Resource Server        │
│                         │                ┌───►│                         │
│                         │                │    │                         │
│                         │                │    │                         │
│                         │                │    │                         │
└──────────┬──────────────┘                │    └─────────────────────────┘
           │                               │
           │                               │
           │                  access_token │
           │                               │
           │ access_token                  │
           │                               │
           │                               │
           │            ┌──────────────────┴──────┐
           │            │                         │
           │            │                         │
           │            │                         │
           │            │                         │
           └───────────►│    Client               │
                        │                         │
                        │                         │
                        │                         │
                        └─────────────────────────┘

Or are you actually asking about the authz server and resource server being the same application (microservice) instead of separate applications?

[zxuanhong]

@sjohnr Like this(Because the entire service is absolutely trusted, there is no need to use JWT. This reduces the pressure on auth server)

[sjohnr]

@zxiaozhou thanks for the update. However, adding the dashed line doesn't really clear it up for me, because you label everything inside "microservice." Do you mean "microservices" (plural)?

Regardless, I think the main question being asked here is "How do I use opaque tokens?" which is covered in the reference manual (simply set TokenSettings#accessTokenFormat(OAuth2TokenFormat.SELF_CONTAINED) on the RegisteredClient.tokenSettings). You can use the JdbcOAuth2AuthorizationService (or provide your own) to store tokens in the database.

Also, take a look at Configuring and Extending Spring Authorization Server (recent talk from SpringOne Essentials in January, 2023) where we configure and demo use of opaque tokens.

Currently, I'm not sure this pattern you're outlining here is very common. It seems to contradict some of the reasons for choosing OAuth2, though the argument for/against this pattern is probably not productive to hash out here. For that reason, I'm going to close this issue. If the community disagrees and thinks this is a needed use case, please speak up and we can absolutely re-open this issue.