Feature request: add "middleware" to allow the developer to enrich the JWT payload

[mcoquet]

Scenario: As a developer, I may wish to add more content to the JWT payload. This is a very common use case.

Suggestion: If I as a developer could configure a web hook to be used before the JWT is returned, I could create a service to return the payload to be added to the JWT token (inside a payload property for example).

{
...
  payload: {
    // the returned object from my webhook
  }
}

[GJordao]

This sounds good, should we allow users to specify an env variable URL where we would fetch that data and expect a certain format (an object with payload for example)?

@MicroAnibal what do you think?

[MicroAnibal]

@GJordao, this would be a great addition and it would give a lot of flexibility for different purposes. For a first version that supports just one middleware, using a env variable URL should be Ok.

This feature could also halt the JWT generation if we don't add some kind of protection from middleware unexpected behaviour. The basic JWT token generation can be delayed but should not be stopped when middleware fails (this requires more discussion).

Suggestion: Add env variables:

• payloadMaxWaitTime to mitigate/protect from unresponsive middleware.
• payloadMaxSize to limit the expected response size from the middleware.

[mcoquet]

I'd say let's @MicroAnibal 's suggestion is pretty good. Let's do that and see how it flows?

[GJordao]

Not sure if I agree fully. If the middleware is unresponsive do we still generate the token? I think an error should occur to let the users know something is up with service. Creating the token but then not having information the users might need will only create more problems. Ex: token contains permissions, if we generate the token without that payload users might not have access to stuff they need.

As for max size if the users are the ones defining the max size they should just check it on their middleware I suppose. I don't see a point in giving user that control since they already have control on the middleware

[mcoquet]

That's a good point. The token should not get generated. The service should fail with a clear timeout of the dependency. Let's remember this API is to be used by another service and it's not a public facing API, so failing clearly is the priority.

To be honest, the payloadMaxSize does nothing for me either, but I can Imagine it being useful to some people. My thought process was that it can't hurt to add, but if I understand your perspective, you'd prefer to not add the complexity. Am I reading you right @GJordao ?

[GJordao]

Yup that's essentially it

[GJordao]

We can go ahead and implement this:

• Add env variable that specifies the URL to call
• On the login endpoint call that URL
  • If the call fails return an error to the user and don't generate the token
• If the call is successful add that payload to the jwt token