Design questions for a biz. system utilizing an in-house OAuth2 server

My question is about an enterprise system that has its own OAuth2 Authorization Server. In my system(in progress now), there is an OAuth2 Authorization Server, a Resource Server that holds user information, a Resource Server for managing partners, and a Resource Server for managing products and inventory. The way I am implementing this is as follows: All back-end systems are implemented as separate Spring Boot projects — an OAuth2 Client, an OAuth2 Authorization Server, a User Information Resource Server, a Partner Data Server (Resource Server), and a Product & Inventory Management Server (Resource Server). There is a standalone OAuth2 Client (Spring Boot), and a Vue frontend accesses this client. The OAuth2 Client receives a token from the OAuth2 Authorization Server. Using that token, the OAuth2 Client accesses both the Partner Data Server and the Product & Inventory Management Server, treating them both as Resource Servers. However, I noticed that most sample projects take a different approach. They often combine partner management and product & inventory management functionality directly into a single OAuth2 Client. In these examples, the Resource Server is usually only responsible for serving user profile information. I would like to understand why this design is so common. Additionally, in systems like mine that have their own OAuth2 Authorization Server, many sample projects show the OAuth2 Client issuing its own JWT after a successful login. This newly issued JWT is then used for all subsequent requests. I’m curious why the client does not simply continue to use the original token issued by the OAuth2 Authorization Server. I would appreciate your insights on these points.

Mar 16, 2025 - 08:01

My question is about an enterprise system that has its own OAuth2 Authorization Server.

In my system(in progress now), there is an OAuth2 Authorization Server, a Resource Server that holds user information, a Resource Server for managing partners, and a Resource Server for managing products and inventory.

The way I am implementing this is as follows: All back-end systems are implemented as separate Spring Boot projects — an OAuth2 Client, an OAuth2 Authorization Server, a User Information Resource Server, a Partner Data Server (Resource Server), and a Product & Inventory Management Server (Resource Server).

There is a standalone OAuth2 Client (Spring Boot), and a Vue frontend accesses this client. The OAuth2 Client receives a token from the OAuth2 Authorization Server. Using that token, the OAuth2 Client accesses both the Partner Data Server and the Product & Inventory Management Server, treating them both as Resource Servers.

However, I noticed that most sample projects take a different approach. They often combine partner management and product & inventory management functionality directly into a single OAuth2 Client. In these examples, the Resource Server is usually only responsible for serving user profile information. I would like to understand why this design is so common.

Additionally, in systems like mine that have their own OAuth2 Authorization Server, many sample projects show the OAuth2 Client issuing its own JWT after a successful login. This newly issued JWT is then used for all subsequent requests. I’m curious why the client does not simply continue to use the original token issued by the OAuth2 Authorization Server.

I would appreciate your insights on these points.