Custom Payload for the JWT tokens

[futurbotconsolidated]

Hi! @wagnerdelima, I have been using this lib from a long time now. I was implementing micro service architecture now but somehow I am facing dependency issues because of tokens I get. Since JWT Tokens are supposed to used everywhere to manage the user state but since we just get the following data

{items "header":{ "alg":"HS256" "typ":"JWT" } "payload":{ "token":"oJI1lNKgIV7ZboZ1H5jrFTBojO4uJh" } }

It is difficult to use the same authentication everywhere. Hence difficulty in using micro service architecture.

Proposed Solution :

1. Able to manage the Secret which generate the JWT Token so we could handle authentication in any tech stack linked
2. Able to add additional data in payload (ex: username, validity)

I am calling authentication API to check the token before handling request.

I have also made a extra custom JWT token to pass with another API to manage this. Both approaches worked for me. But it would be amazing if I manage this this lib

I am more than happy to work on this if you think it is something we should brainstorm upon.

[wagnerdelima]

@futurbotconsolidated First of all, let me express my thanks for using the framework.

I also appreciate that you have presented this idea. I am actually looking for new ideas to implement. Given what you presented, I didn't quite understand the first point: "Able to manage the Secret which generates the JWT Token so we could handle authentication in any tech stack linked"

As I see it, this is more of an architecture problem than a framework problem. In a microservice architecture, you would either need of of the three of very similar concepts in your architecture design:

1. Centralized Authorization Server: One approach is to have a centralized authorization server that all microservices can use to authenticate and authorize access to protected resources. Each microservice would act as a resource server and the authorization server would handle the authentication and authorization. The authorization server would also generate access tokens that are used to access the protected resources.
2. Distributed Authorization Servers: Another approach is to have each microservice act as its own authorization server. In this approach, each microservice would handle its own authentication and authorization, and issue its own access tokens. This approach provides greater autonomy to each microservice, but it can be more complex to manage and requires more coordination.
3. API Gateway: Another approach is to use an API gateway as the entry point for all requests to the microservices. The API gateway would handle authentication and authorization, and pass on access tokens to the microservices. This approach can simplify the management of authentication and authorization, but can introduce additional latency and complexity.

I am not quite sure how you designed it. Let's brainstorm it here.

Thanks for opening the issue.