Kong and JWT - how the APIs should extract the info from the token

Question

today I started looking at Kong and how it provides some functionalities through plugins. I was reading the [enter link description here][Plugins] page and started looking at the JWT.

It seems that Kong offers these endpoints (and not only):

• Create a Consumer;
• Create/Delete a JWT credential;
• Generate a JWT token with credential taken from step 2;

Once active, Kong will verify the validity of the JWT (and claims) and forward to the APIs endpoint the request if it's valid.

Here are my questions:

1. Since JWT is used also to carry info (e.g. customer ID, customer role) in order to have always a subset of the user info in every API without querying every time the DB or other endpoints, how can each API parse the JWT token and extract the info in it?

2. Imagine I want to create a single page application that interact with Kong that hides many microservice. Which is the best way to use JWT that each backend microservice can parse the JWT token in order to retrieve for instance the user ID that made the request?

3. Does kong offer an api to parse the JWT token?

Answer 1

1. You can either use a JWT library like JJWT for example to decode the token in your API endpoint implementation or you can use a dedicated microservice that would decode it for you

2. You would generate and access token when you authenticate the user then send it in the header of each request after that. This way your microservices can validate the user via one of the options described at #1

3. Doesn't look like it does

Answer 2

Please check the following link, the plugin will parse your JWT token and decode it: https://github.com/wego/kong-jwt-claim-headers

Also if you need help to setup the jwt plugin please check: Kong-auth0-jwt

Answer 3

Another option is to use kong-oidc and deploy it as a Resource Server, validating OAuth 2.0 JWT tokens.

Answer 4

I had a similar requirement. I achieved it by adding the JwtFilter in my spring-boot application which will extract the JWT token, parse it and set it in the SecurityContextHolder. I could extract the user information by fetching the token from SecurityContextHolder wherever required. The challenge I faced though, was identifying the secret which was used by signing up the JWT, as I had no control over how was is it generated at the consumer end.

Answer 5

Actually, once Kong verify the JWT token associated to the consumer, it will put extra information in the request headers like x-consumer-custom-id, x=consumer-username, x-consumer-groups, etc...

If you're willing to add a consumer entry for each user you have in your database, associate the custom-id of your consumer to the real user id of your database.

Then for each request you will be able to identify who was the issuer.

If you want more information and still want to use the JWT plugin, you will have to use extra components (JWT library, Third-part service, etc..).