Spring Boot with common Authentication

Question

I am trying to set up authentication server for spring boot application. I have multiple microservices application. Let say hospitals, patients, reports applications. I have each of microservices service application to be authenticated before allowing user to access the resources. Can I know how can I have common authentication logic as a separate application. let say authentication application. I am planning to us (spring security with Auth 2.0 and JWT token).

For example:

When user tries access hospital dashboard page, we will check the user is authenticated

• First we need to check whether user is authentication if not I need to redirect to login service in authentication application.

  Once user is logged in, then when he try to access dashboard we will check the token is valid. If valid then allow user to access the dashboard service.

• Now user try to access patient details which is there in patient.war as a separate project, as the user already logged in we need to valid token, then we need to allow access to resources API what he is trying to access. If token is invalid then we need to redirect to login page.

Question:

1. I have gone through some example they have authentication server and resource server as separate application. i.e @EnableAuthenticationServer and @EnableResourceServer. But I have noted this got deprecated in latest spring boot version if I am right. Please correct me if I am wrong.

2. How can I have authentication functionality as common war file and let the other resource server access it before allowing the user to access the reset service API?

3. Which is the right way to build a microservice application?

I need some experts help to understand the best approach we need to implement authentication and authorization in latest spring boot version.

Answer 1

This is a relatively older question but I'll answer since it may help others.

For any microservices-based architecture, the api gateway is an important aspect and it should be there.

All your microservices will be hiding behind the gateway and any calls made to the downstream services (hospitals, patients etc) will go through the gateway.

This gives you multiple advantages.

1. You can add login (authentication) functionality in the gateway
2. You can put rate limiter to avoid DOS attacks
3. A single point of entry for the outside world so your clients don't neet to know the URL of each microservice

Now, the way it works is:

1. The client sends username/password or client_id/client_secret to the /login endpoint which is inside the gateway (for example GatewayController)
2. Gateway sends credentials to an "Auth-Service" which authenticates the user from a db or anywhere and creates a JWT (Oauth token)
3. Gateway returns the jwt back to the client
4. Client calls the, let's say, /patients endpoint through gateway with the jwt as header "Authorization" parameter
5. Gateway -> Auth-Service (To validate the token)
6. If invalid, 403 forbidden is sent. Otherwise, request is forwarded to the downstream service (in this case Patients-Service)
7. Patients-Service sends the jwt token to Auth-Service to get permissions from inside the token since we know that the token has already been validated.
8. Once the permissions list is received, the Patients-Service matches them with the permissions mentioned on each api (for example PatientsController)
9. If any permission matches, the response is served. If not, 403 forbidden is served.

To make it more clear, Auth-Service is called once when the call is for login(authentication). Auth-Service is called twice for all other api calls(validate + permissions).