I have currently a doubt about how are people doing this the right way.
As of today I have a Spring Cloud Gateway microservice and behind it I have other two microservices, the security microservice is tasked in registering clients, log in, logout and validate JWT, the other microservice is one that I have mainly for CRUDS.
My problem is that I had the idea that in my Spring Cloud Gateway I was going to redirect first EVERY request to the /token endpoint in my security microservice to validate the JWT and if it's successful, reroute the request back to where it initially was requested for example "/clients".
My gateway doesn't handle anything about security or tokens that is just tasked on the other security microservice. How are people doing it these days? If i wanna go these route is it possible?
I have been looking to implement my idea but haven't found something like this or if this idea is actually bad and I should migrate my security microservice to be in the gateway somehow.
Related
Looking for suggestions on how to go about with microservices authorisation.
I'm using the spring/spring boot for all them microservices
I'm able to authenticate via spring cloud gateway before reaching the actual microservices using JWT tokens however when it comes to authorisation i'm unsure on how to do it.
I would like handle the authorisation internally for each of the endpoints in the business microservice.
Is there a way to pass the JWT token to the microservice or do i need to call the authserver to get the roles within the user ?
Actually, both works.
You can put the roles in the token, when you need it, decode it. Or decode it in the gateway and pass it all the way.
If you don't want to put too much data in the token, you can call the auth server as needed.
I am new to spring microservice world. As I am in learning phase, I tried and implemented the following things.
Authentication/Authorization as a separate microservice
Routing (Able to route using Spring cloud gateway)
Load balancing (Netflix Eureka)
Rate Limit and Circuit Breaker (Resilience4j)
I just need certain clarification and suggestion on what to do in these situations:
As I already had created Authentication/Authorization as a separate microservice centralized.
Now how can I implement such that every request must contain jwt token and pass-through API gateway to call other microservice also it should check which user has permission to access API in other microservice
If some has same good source so that I can learn please do share or if someone has a basic skeleton on GitHub.
Requests from outside your cluster should be intercepted/validated by Zuul (example) will be your gatekeeper which will pass the request to the request checker in this case would be your authentication service where the acquired token will be validated (this should exists at the header of the request). One tokens are validated, the request will be routed to the authorization service to check if the user has access to particular endpoint based on your rules defined for access.
microservices architecture
I have a micro service(userservice:user related microservice) but in Zuul API gateway application i want to authenticate requests for all microservices and use spring security. I have to create signin and signup requests(AuthController) in Zuul application which require datasources,userRepository all things in zuul application.
If i use userservice(microservice user related)for other user related requests then i have use same datasource and create duplicate beans and repository for same data source which i already created in zuul api gateway application ?
I don't feel it would be a good design to authenticate usenames and passwords at gateway level. Instead what you can do is, you can add JWT tokens which can validate the request itself in zuul filters. This can be one level of verification at gateway level.
Second, you can implement caching at api level which would significantly increase the throughput of your backend security api.
I want to use Keycloak in a microservices based environment, where authentication is based on OpenID endpoints REST calls ("/token", no redirection to keycloak login page), a flow that I thought of would be something like this:
1. Front-end SPA retrieves the tokens from the "/token" endpoint and stores in browser's localStorage, then sends it with every request.
2. Gateway-level authentication: Acess Token is passed from the front end to the gateway, gateway consults Keycloak server to check if the token is still valid (not invalidated by a logout end-point call).
3. Micro-service based authorization: Acess Token is passed from the Gateway to the microservices, using Spring Boot adapter the microservices check the signature of the token offline (bearer-only client?) then based on the role in the token do the authorization.
My questions are: Does this flow make sense or can you suggest another flow? What type of Keycloak clients to use? What's an ideal way to pass Tokens using Spring Boot Adapter, and should it be done like that in the first place? Please keep in mind that I am not a Keycloak expert, I've done my research but I still have doubts.
Your Front-end SPA should be public-client and springboot micro service should be Bearer only Client and Gateway could be Confidential Client.
You can check the Keycloak provided oidc adapters. For springboot you use the keycloak provided adapter
Similar solution using api gateway is discussed here
I'm about to implement a token based authentication system with Spring Boot and Json web token. I have a frontend app built with Angular. My understanding is that once authenticated, all API calls from the angular app will send the token to the server to be verified before a response is sent back.
I'm wondering then how Spring Security would fit into the picture. It seems like it is no longer necessary if I just use the server to verify the token every time the frontend makes a call.
My question is whether or not Spring Security is required in this instance and if it is, what role will/can it play?
I would like to know from the outset before diving in. Thanks!