Authenticating with Kong
I am looking at Kong to replace my current manually collapsed NodeJS API gateway. I currently have a custom service that handles authentication (written in Django) by providing a JWT on login, which the client then passes through the header. My current API gateway then intercepts any calls, makes a callback 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 about the same thing. I'm trying to figure out how this should work in an ideal world. I still have the ability to replace most of the infrastructure, so rewriting some of the services is possible.
So, in my opinion, what will happen is the following:
- A user registers on my site. Then I create a new consumer with his username / id in Cong
- The user is logged in. This is where I get stuck. Should I log in (or in this case just authenticate the user as the specified user), ask Kong JWT for that consumer, and return it? What if I would like to get more data in the JWT payload? What happens on the Kong side when the JWT expires?
- When a user requests a service, Kong will extract the JWT from the headers, replacing it with
X-Consumer-*
- is that correct?
Please correct me if I am wrong or if there is a better way to achieve this. I am new to everything about microservices.
source to share
I am working on a similar setup and these are my findings / conclusions at the moment:
The user must register as you describe.
On login, I believe there are two possible ways to solve this problem:
- Store user_id in your custom database,
- Store the jwt key and secret in your user database.
In scenario 1, you need to get the jwt key and secret from kong and create a jwt token and use that token to make requests to your kong services.
Scenario 2 is pretty much identical to Scenario 1, except that you don't need to make any requests to kong in order to generate the jwt token.
You can add additional payload parameters to the jwt token, but they are not passed to your upstream services. However, it looks like this plugin solves this problem (I haven't tested this yet):
https://github.com/wshirey/kong-plugin-jwt-claims-headers
Kong passes the user custom_id and username from user jwt to the upstream service after authorization, for example:
x-consumer-custom-id: [245]
x-consumer-username: ['my-test-user']
x-consumer-id: ['1e9e25dd-396f-4195-94fc-f2a8bd8447a2']
It also passes the entire authorization header
source to share