I had an application developed in monolith architecture. It had all the authentication and authorization needed.My application front end is in angular and back end is in nodejs. I have jwt token generated from front end. Now I started implement micro services for each module but I don't know how to implement authentication and authorization so that all the services can use it. I read different article on it but still unable to find solution.
Below 3 step process need to be implemented for authentication & authorization solution :
You can create auth micorservice using spring oauth 2.0 which takes care of user authentication and generating the JWT token after successful authentication, Here existing monolithic code can be utilized upto some extent.
Now, Using API Gateway design pattern, JWT token can be authorized in each API call at API gateway layer only, Means We can validate the JWT on API gateway itself before passing it to the backend microservices.
Further, From API Gateway forward the coming Bearer token to the backend microservices where method level authorization can be taken care of.
Related
We have a set of microservices where some are public facing for our UIs to call. The UI sends a JWT user token (obtained from the user login with keycloak) on requests to a microservice and that microservice may need to call another microservice. What is the best practice for sending a JWT from one microservice to the other. i.e.
microservices just pass through the original JWT user token to other microservices
microservices do a token exchange with the original JWT user for a JWT service token and inject the claims from the original into the new service token.
microservices obtain a JWT service token and sends that in the Authentication header and also sends the original JWT user token as some other header
microservices obtains a JWT service token and adds the original JWT user token as a claim in the new token.
some other mechanism not mentioned
Thanks.
that microservice may need to call another microservice
Personally I would not allow such inter-microservices calls.
Instead, I would introduce a kind of "facade" (typically named an "API Gateway") in front of all micro-services, whose API will be invoked by the front-end.
Every coarse-grained service exposed by this facade is likely, behind the scenes, to chain N calls, potentially to different (fine-grained) micro-services.
This architecture allows two distinct security schemes
JWT tokens for cross-layers communication (ex: FrontEnd -> API GW; API GW -> micro-services)
BASIC auth account + mutual TLS when backend -> backend communication is needed
Nice article:
https://medium.com/ballerina-techblog/securing-microservices-with-jwt-a16b738b110f
My 2 cents,
I am currently implementing a API project using express-js.
There are multiple clients for the API. This includes a front-end web app and some backend services.
I am looking at using a normal session based management for authentication using express-session.
I am preferring this over jwt since session based + secure cookies is easier for many use cases which I would need need
Ability to revoke user access from server side
Allow only single active web session for a user
I am sure I can maintain a separate persistance table with userid + refresh_token + access_token to achieve the above.
Its just that session based gives me these in straightforward.
Now when it comes to my daemon services, I would still like them to go via API route. This will be more like Client Credentials Flow.
Since these are non-http clients, cookies will not be supported.
I am not sure how my app can API's continue to support both of them ?
The only option I have now based on readings on various blog sources is to use JWT in the cookies for the web front end and using JWT as bearer in header.
This means that
I will need to implement all the security mechanisms like token black-listing, regenerating refresh_token etc.
I will potentially lose out on main benefit of JWT of statelessness.
What are the options I have to ensure that my API layer can support both front-end web apps like react/angular and other micro services
The standard solution here is to use an API gateway:
APIs receive JWT access tokens regardless of the client, and validate them on every request
Browser clients have their own routes to APIs, and send cookies that contain or reference tokens
Mobile clients call API directly, but with opaque access tokens
APIs call each other inside the cluster using JWTs, typically by forwarding the original token from the web or mobile client
The API gateway can perform translation where required. Here are a couple of related articles:
Phantom Token Pattern
Token Handler Pattern
Done well, all of this should provide a good separation of concerns and keep application code simple.
I am wanting to build a authentication/authorization service using NodeJS, Mongo, and JWT. This service would be a micro-service that handles requests not only from my API Gateway before allowing requests, but from other services that might want to check auth and roles. I am assuming that all other services will use this Auth Service to validate the JWT as well as roles, etc.
Hopefully this diagram better explains what I am looking for.
Can anyone point me to a resource that might help me learn how to do this with NodeJS?
If you have a single client application then you can do following steps
Make one microservice for authentication that generates jwt token.
The jwt contains all essential user information in its payload, ie Role, UserId etc.
The jwt token will be sent in Authorization header for every authorised request.
Before processing any request you can validate and decode the jwt token using middlewares. Now you can set the user's info in req object easliy and can easily access users role and its id in your controller.
if the token is not valid then you can throw error in middlewares and it will provide json response of unauthorised.
You can call the authentication api to validate and decode your token or you can write 3 to 4 line of code in every microservice in middleware.
Here are some links for sample implementation of jwt, you should customize these sample code according to above steps.
5-steps-to-authenticating-node-js
authenticate a nodejs api with json web tokens
If you have multiple client applications
You should use openid connect standard that provides single sign on solution to authenticate multiple application with same username and password.
here is a openid connect playground to understand the authorization flow.
As I'm trying to create a unified OAuth2 system for an internal custom userbase system a question/problem arouse for which i couldn't find a fitting documentation:
In our microservice application/service structure we have several (web) application clients which usually have either a separate application server or contain all logic in the client. They are trying to access a network of microservices. Some API's are accessed directly while some are accessed through other services.
To protect these resources I envision a system similar to the following:
The diagramm is mostly oriented at a Node.Js + Passport heavy structure but other technologies are in use in the real-life structure.
Here the client/application server will handle the full login and authorization process directly using the OAuth2 Authorization Server. This will result in the client/application server having a valid access token.
Using this access token it can then access the API's by using the token as a Bearer token in the Authorization header of the request.
The API can then check this token by validating it against the Authorization server. Afterwards it could also temporarily save the token to not validate the token on each request but rather store it with a TTL.
When a service is internally accessing another service it should then just pass the Access token along so the next service can again validate it.
Is this the preferred flow/setup for such a case or am i making a mistake here?
Is there any problem if I sent the identity token, which has been issued from a trusted IdP, to javaScript code in order to use it in calling a web method with authentication?
Is there any security concern from doing that whether the token is encrypted or not!
In my case, there is a web application which is asking an IdP to authenticate users. I'm using a WCF web service with Ws2007FederationBinding in order to send the security token. Everything is fine when I call the service from the server, but now how can I consume it from the client side using JavaScript as well?
I'm not familiar with Ws2007FederationBinding. Considering that you need to do calls from the client side, I don't see a problem with embedding that token in the client.
I believe that's as the same when you need to use an external API and you have some kind of "auth" token associated to your service.
Ws2007FederationBinding is a SOAP binding with a SAML security token in the envelope. It will be very difficult to call a service with this binding from JavaScript.
This binding requires the client to talk to an STS to get the SAML token and prove it was the requester of that token (holder-of-key) to the service (relying party). This involves cryptographic operations that are hard to do in JavaScript.
The 'best' way to solve this issue is to create RESTful proxy services that your JavaScript layer talks to and have this REST service talk to the SOAP backend services. You should secure the REST services with a bearer token (JWT) and exchange it for a SAML token before you call your SOAP service.
You can use the JWT token handler class in .NET for the translation between JWT and SAML.