Authentication with Kong

Question

I'm looking at Kong to replace my current hand-rolled NodeJS API gateway. Currently I have a user service that handles authentication (written in Django) by providing a JWT back upon login, which the client then passes in through a header. My current API gateway then intercepts any calls, does a validation call back to the user service, and replaces the JWT Header with X-User-Id and X-User-Email.

As far as I can tell, Kong can do roughly the same thing. I'm trying to figure out the flow of how this should work in a perfect world. I still have the opportunity to replace much of the infrastructure, so rewriting some services is not completely out of the question.

So, in my mind, what would happen is the following:

1. User registers on my site. I then create a new consumer with their username/id on Kong
2. User logs in. This is where I get stuck. Do I log in (or in this case, simply authenticate the user as being said user), ask Kong for the JWT for this consumer, and return that? What if I wanted some more data in the payload of the JWT? What happens on Kong's side when the JWT expires?
3. When the user requests a service, Kong will the sniff out the JWT from the headers, replace it with X-Consumer-* - is that correct?

Please do correct me if my thinking is wrong, or if there is a better way to achieve this. I'm fairly new to the whole microservices thing.

Answer 1

I'm working on a similar setup and these are my finding/ conclusions at the moment:

User sign up has to be the way you describe.

Upon login I do believe there are two possible ways to solve this:

1. Store the consumer_id in your user database,
2. Store the jwt key and secret in your user database.

In scenario 1 you'll have to get the jwt key and secret from kong and generate a jwt token and use this token to do requests to your kong services.

Scenario 2 is pretty much identical to scenario 1 except you don't have to do any requests to kong in order to generate a jwt token.

You can add additional payload parameters to the jwt token but these are not passed down to your upstream services. It does however seem like this plugin solves this issue (I have not tested this yet):

https://github.com/wshirey/kong-plugin-jwt-claims-headers

Kong passes on the custom_id and username from the jwt consumer to the upstream service upon authorization, like this:

x-consumer-custom-id: [245]
x-consumer-username: ['my-test-user']
x-consumer-id: ['1e9e25dd-396f-4195-94fc-f2a8bd8447a2']

It also passes on the entire authorization header