Inter-service communication with Spring Boot and OAuth2 - spring

Question

I am working on a micro-service architecture using Spring Boot. We have implemented OAuth2 in a Auth Server.
My question is - If two microservices want to communicate what should be the best way?
As of now, I have discovered below options:
If each microservice is verifying the token then we can pass the same token. But the problem is - in between same token can be expired.
If we use client_credentials grant then there we are having two issues: one is, we need to send the username in next microservice. Another one is, we need to request two times - first for getting the access token, next for actual call.
If we do the token verification in API gateway only (not in microservices) then from the API gateway we need to send the username in every microservices. And microservices implementation needs to be changed to accept that param/header.
Please suggest which option should I pick and if there is any better option please let me know.
Thanks in advance.

Answer 1

Not an expert either, but
If we do the token verification in API gateway only (not in microservices) then from the API gateway we need to send the username in every microservices. And microservices implementation needs to be changed to accept that param/header.
could be changed this way:
You make authentication/authorisation the problem of the gateway.
When gateway authorizes the client, it attaches JWT token to every microservice request its going to make on behalf of the client (instead of sending username). JWT will contain all information that microservices might need. If the microservice will need to call other microservice, it will need to pass that token further with the request.
So the idea is - for EVERY request that comes through the gateway, a NEW JWT is being attached to the request. Then you don't have expiry problem and tokens are easy to verify.

Answer 2

I am not an expert on OAuth, but I have done a fair bit of work with microservices. When working with microservices, it is often a good idea to separate your services in such a way that:
They each know as little as possible about the concepts/concerns that they delegate to other services
Their dependency graph is acyclic, whether the services are microservices or part of a well-designed monolith
Take an example of Accounts and Orders. You could have the Accounts service know about users, authentication and authorization, sessions, and contact information. If a user wants to view an order, the accounts service could take all requests, ensure that the user is authorized to do so and then request the order directly from the Orders Service.
The downsides to this approach are:
The Accounts Service must pass all orders data through to the user client, which may result in code duplication and complexity
Changes to the Orders Service API may require changes to the Accounts Service to pass through new data
Upsides are:
The Accounts Service can authenticate with the Orders Service directly using a service-level authentication mechanism like an api token
The Orders Service may live on a private network
Another approach might be to have a third service responsible for identity. The client would make requests directly to the Accounts Service and Orders Service, which would each then ask a third service, let's call it an Identity Service, if a session is valid. If not, it would forward the user to authenticate (sign on) with the Identity Service. Then on each request from the client to the Accounts Service or Orders service, these services would check with the identity service if the session is still valid.
Advantages to this approach are:
The Accounts and Orders Services do not need to know about usernames and passwords
Each service simply provides the data it is responsible for directly to the client
Downsides are:
This architecture is a bit more difficult to set up
A third approach is to implement either of these approaches into a single service. In the case of accounts and orders, I might make an argument that they are very closely related and that splitting them out into separate services may not improve your architecture.
As I said, I am certainly not an expert in OAuth, but I have worked a fair bit with services and microservices.