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
Related
I'm having a hard time figuring a good way to implement Oauth 2.0 and OpenID Connect authentication alongside an existing internal email+password authentication for a B2B Web app's API using Spring security.
We have a backend REST API that is a Spring Boot servlet application which currently authenticates users with OAuth 1.0 and the password grant. The front-end is an Angular single-page app through which users must log in with their username and password. The API's /oauth/token endpoint then delivers an opaque access token to be used for fetching secured resources that are then displayed within the app.
We'd like to add the possibility to log in using external authentication with OpenID connect, which is a perfect opportunity for switching to OAuth 2.0 and JWT tokens. Our API would then accept JWT tokens it delivered as well as external JWT tokens emitted by accepted issuers.
Reading and validating JWT tokens won't be a problem using Spring security's OAuth Resource Server. However things get complicated with how to make the classic username+password login flow work with JWT tokens.
We thought about delivering JWT access tokens the same way we used to with our old OAuth 1.0 tokens. The thing is, newer OAuth specifications advise against using the password grant, plus it simply isn't supported in the Spring authorization server project we're planning to use. The authorization-code flow w/ PKCE seems like too much for this case as we do not want the back-end API to render a login form but use credentials entered in the existing login form that is part of the single-page app.
I've read a lot about not using OAuth for 1st party login since its primary use is for external authentication, but again, that doesn't apply since we also want 3rd party authentication.
What would be a secure way to implement a Spring boot authorization server that can deliver JWT access tokens to a 1st party client in exchange for a user's credentials, all this using the existing log in page, and given the password grant type no longer being supported?
I thought about implementing a preliminary step that would be a POST request with Basic authentication to a /login endpoint that just returns a 200 HTTP status, then proceeding to the /oauth2/authorize request that would deliver the authorization code immediately without redirecting since my session is authenticated.
I'll be happy to provide more details if needed. Here are the resources I'm using for this project.
What about setting up an authorization-server capable of identity federation?
In such configuration, the authorization-server is responsible for providing with identities, proxying one or more sources (your existing user database for instance, plus maybe Google, Facebook, Github, etc.)
Keycloak does it for instance.
From the client point of view (your Angular app), the authorization-server is used to get:
access-token: put in Authorization header of requests to secured resource-server(s) (can be a JWT or an opaque string, doesn't matter, clients should not try to extract data from access-tokens)
refresh-token: send to authorization-server to renew access-token before it expires
id-token: get user-profile data (email, username, profile picture, etc.)
You should have a look at https://github.com/damienbod/angular-auth-oidc-client for connecting an Angular app to an OIDC authorization-server.
From resource-server point of view, access-tokens are the source ofr setting-up security-context, either by decoding and validating a JWT locally or with token introspection on authorization-server.
Have a look at those tutorials for such resource-servers configuration.
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?
In a context with the following services:
API Gateway/OIDC client: connect to an external OpenId Connect Provider (to get access, refresh and id tokens) and act as proxy to forward requests to other services with the access token (Authorization code flow)
Several resource servers, incoming requests are handled by the API Gateway and include the access token (for validation, using the keys exposed by the OIDC provider)
I am using the Spring Security 5.2 Oauth2 client/resource server libraries.
What will be the recommended secure way to make all the resource servers services aware of the user information (included in the API Token).
I am evaluating several options:
Include the id_token in the request sent to the services. Each
service can then validate the token (in a filter).
Make the API Gateway act as a token issuer to make a new enhanced token based.
The resources servers will have to validate the token received with
a new key exposed by the API Gateway/Token issuer. With this
solution a custom AuthenticationManager has to be implemented.
I think option 2 is the more secure and future proof, is there any downsides I should consider? Also there are maybe other alternatives.
You should be able to achieve your goals without issuing a second level of token or sending id tokens to APIs. A common gateway solution is as follows:
Open Id Connect Provider (OICP) issues tokens to the client and does all the deep stuff like auditing of tokens issued + UIs for managing them
Client sends access token to resource server via API Gateway
API Gateway validates the access token, which can involve an introspection call to the OICP
API Gateway can send the access token to the user info endpoint of the OICP to get user info, then forward this to resource servers - perhaps via headers
API Gateway can be configured to cache claims (token + user info details) for subsequent calls with the same access token
Resource servers sometimes run in a locked down Virtual Private Cloud and don't need to revalidate the access token (if you are sure this is safe)
AWS API Gateway works like this when calling lambda functions. I actually like the pattern in terms of extensibility and it can also be used in standalone APIs.
My write up may give you some ideas, along with some sample authorizer code and a class that does the OAuth work.
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.
Is there a simple way to integrate Firebase Authentication with Spring Security (for a REST service)?
From what I've read, I'll probably need to use a JWT token (obtained via Firebase), use that to authenticate the Spring service, and finally verify the token within the service via Firebase. But I can't find any (simple) documentation on using JWT with Spring Security.
I'd also like to be able to provide an /auth/login endpoint that uses Basic Auth rather than JWT so that I can obtain a JWT token via Firebase using email/password credentials. But this would mean enabling Basic Auth at one endpoint in the service and JWT Auth at all others. Not sure that's possible.
Short answer: no.
Long answer: you should create your own JWT, regardless of Firebase. When you receive a JWT from Firebase, verify its integrity. Then, issue your own based on the data in the token. Then you only need to adapt it to various OAuth providers. This way you can avoid round trips to firebase on each request.
For authenticating the user on each request (stateless auth), you add a filter with highest precedence. From the http request you are filtering, get the JWT and verify its integrity. If it's all good, set the authentication in the SecurityContextHolder.