i am creating a spring microservices project. my project is composed of eureka, spring cloud gateway and other microservices.
what i am doing is validating user jwt in spring cloud gateway, but validating the token only is not enough, i also want to check if user state is valid or not, for example I want the gateway to return to the client "UNAUTHORIZED" if his account is banned.
what i'm doing now is letting the user use his token until it is expired, but once the token is expired and the user tries to renew it, i inform him that he's banned and he can not get a new jwt.
what i want to do is block him even if his token is not expired yet, i don't want him to access endpoints once his account is suspended.
I know that I can call the user microservice in the gateway filter to obtain his state .. but I don't want to do this on every api call, because i think that's a little more expensive.
Are there solutions to manage this situation?
Related
We're currently using jwt token based authentication in spring gateway service, where we generate token by providing username and passwords, then token is generated with required attributes.
Planning to integrate current login flow along with keycloak sso using IDP for this instance let's say azure-ad.
What would be better way to implement it, keeping the flow in sync with normal credential flow for generating JWT tokens at gateway?
As of now, We've tried the flow where user is sent to IDP's login screen, login event is captured on keycloak and sent to custom event handler (SPI), SPI fetches user attributes and generates token from project's user database and adds to keycloak specific db if it's not there.
There are several approaches for managing authentication in microservices including service to service authentication. I want to understand which approach is better.
When a user logs in to the system auth-service call is happening and the auth-service returns an opaque token (not JWT), then each API call contains that opaque token Gateway validates the token through the auth-service generates a new JWT token for downstream services. So downstream services will not have to call auth-service each time to validate the token.
From the beginning auth-service will generate a JWT token.
2.1. Gateway will validate and pass it through downstream services and all services will use the same token
2.2. Gateway validates and generates a new token each time, and also downstream services do the same.
Each approach has its pros and cons.
Questions:
Approach 1. Gateway each time needs to doo auth-service call to validate?
Approach 2. What will be the expiration time for JWT tokens? Who needs to handle the expirations, what token expires in between who needs to regenerate it again? JWT tokens must be short-lived, so whether it will not affect client behavior, or refresh tokens should come in the picture here.
So I am confused about which approach is good,or are there other approaches.Please advise me.
JWTs should be avoided to be exposed to the outside world since these could potentially include sensitive information in custom claims. Especially if you work in a large company, where you can't keep track of what ends up in different claims.
So if using opague tokens (which you should) the gateway should verify and exchange the token to a JWT that can be used internally inside your network.
All services SHOULD always be setup with zero trust in mind.
All services should if possible fetch JWKs to verify the incoming JWTs. And these JWKs should be rotated on a regular basis.
This is to avoid that if a malicious actor gets access to the internal network he shouldnt be able to do any request to any service just because he has passed the gateway.
When it comes to expiration times, these should be set by the issuer and should be kept short because one of the big problems is that its easy to issue a token, but harder to revoke one.
The flow is usually as such:
Client logs in and gets issued a AT (access token) and a RT (refresh token)
Client presents opague AT token to a service in the backend
Gateway exchanges the opague token for a JWT
Gateway passes the JWT to the service that is requested
The resource server validates the JWT
if request is denied a httpstatus of 401 is returned to the calling client
the client receives the 401 and then presents its refresh to the issuer that will issue a new AT token.
request is redone with the new AT token.
I am working on a microservices project involving 4 services - Auth Service, Service-A, Service-B and Service-C.
All the services are implemented using Spring Boot. The Auth Service is responsible for authenticating logged in user and generating a JWT bearer token. Each of Service-A/B/C has JWT filters which checks for validity of token and then provide access to the Rest APIs.
Now I want to implement logout feature. The logout request goes to Auth Service. The Auth Service uses Redis. The token is added to list of invalid tokens with ttl set so that after the expiry the token is removed automatically.
Now how can JWT filters in Service-A/B/C access the blacklisted token so that Rest API access is approved/disapproved? If all the services are deployed in same system the services can access Redis easily. If the services are deployed in different systems, how can they access the invalid tokens?
Should I implement pub/sub messaging and each service will listen for logout event and update their blacklisted tokens
Or is there a better approach in microservices environment?
One possible solution is to implement filter at API gateway level. See below link ... https://softwareengineering.stackexchange.com/a/430024/395671
How API Gateway and Micro services works.
Could anyone explain the basic flow of Micro service architecture with Gateway. I couldn't find the proper answer.
Say we have auth server and customer micro service running on separate instances and in front of all the services we have an API gateway.
My question is.
when user try to log in using username and password, the API gateway call auth server and return the access token to user.
Then user trying to access the specific url (/customers - customer micro service) that is running on separate instance.
what API Gateway do ?
validate the token with auth server and get the user id and pass the request to customer service with the user id ?
OR
validate the token and pass the request to customer microservice with the access token ? and customer microservice responsible is to the check the user id (Make an HTTP call to auth server) ?
I think that the most common approach is to use API gateway also as a security gateway, which means that API gateway is responsible for SSL termination and token validation. If token validation is successfully you can put user ID or user API key as a header and forward the request to microservice. Moreover you may also decide to perform not only authentication but also authorisation on the API gateway (usually with help of API management solutions).
Regarding your option #2 - I see no point in validating token 2 times. Best practise is to perform security validations on the edge, because in case of failed validation you use less resources (reject earlier)
To Answer your question , it is close to option #2 that you have mentioned . The API gateway will generally check the validity of the authentication token and then pass over the request to your micro-service . However you need to decide at design time if your micro-service will also do another level of verification of the token.
Please do note that the API gateway will not be enforcing Authorization , the authorization is something that your micro-service will have to enforce.
We have implemented a RESTful API using RestEasy. Now we are planning to build our own OAuth implementation and will integrate it with our Rest API.
I do not fully understand how OAuth handles authorization of every request to the API. My understanding is as follows:
User is authenticated by the OAuth server before any REST API calls are made.
Every REST API call will contain a token. The REST API server validates this token with the OAuth server. If the token is valid then the server will return a response.
This should have an impact on performance as we are validating the token for each and every API request with the second server. Is this understanding correct?
This will depend on how you will define your REST API. Basically OAUTH call has following components.
User: Who makes a request.
Provider: Who holds user information and provide apis to access them.
Consumer: Who asks the user to authorize the consumer to make request to the apis.
The basic workflow is as follows,
User tries to access restricted resource from Consumer.
Consumer asks user to share some information about him.(scope)
User selects his identity provider.
Consumer should be known to the Provider.(Usually consumer register itself as an application/website in provider's portal)
Consumer redirects to the provider with his consumer_key and scopes.
User authorize the application and grants access to some of his resource.
Provider creates a token and redirects back to consumer.
Consumer exchanges this token and its identity to get a access_token for user.
Consumer uses the access_token to make authorize request to provider and asks few information about user.
Provider sends those information to consumer.
Consumer verifies the information and user is logged into the system.
Now each token is generated against the scope and will be valid for some days. Token validation will be part of response from Provider.
In your system, you can store user data against token, so that we need not request Provider to send those information. But if you dont want to store user information certainly there will be additional calls.