I am in the process of setting up a central JWT authentication / authorization service. We will have multiple APIs that a client will need to communicate to and be authenticated against.
My thought was to have the user login, which would authenticate against the JWT server. It then uses that token to communicate with the other resource APIs. Those APIs would validate the token against the JWT server before sending the request back.
Is this a pretty decent approach to the problem? Has anyone implemented something like this? One issue I see right away is there is a lot of communication to the JWT server.
This sounds like a decent approach. I have implemented a solution where the JWT service was a part of my API. As i understand from your question, you want to have this JWT service separately so that a user can interact with different services/application using the same token. This is called Single Sign On.
If you think your JWT service is getting a lot of traffic, you can always spin up more instances to handle the additional load.
As long as your service is just getting token from a database and responding to request quickly and not doing any calculations, i do not see it getting affected by a lot of traffic.
