JWT requires unique key across all consumers?

[jxstanford]

Summary

I've been working to integrate Auth0 with Kong, and have most everything working, but only for a single user. As far as I can tell, Auth0 uses a single key and secret per application to sign all tokens, and there isn't a way to change that.

Kong appears to expect both of these values to be unique across all consumers. So, when I try to set up a second consumer's JWT, I get a 409 response back.

The ask would be to relax the uniqueness constraints on the key and secret.

Steps To Reproduce

1. create a JWT for a first consumer
2. create a second JWT for another consumer using the same key and secret
3. POST /consumers/consumer_1/jwt (success)
4. POST /consumers/consumer_2/jwt (fail with a 409)

Additional Details & Logs

• Kong version ($ kong version)

0.8.3

• Kong configuration (registered APIs/Plugins & configuration file)

JWT plugin

• Kong error logs (<KONG_PREFIX>/logs/error.log)

Credential creation returned an unknown error. Status: 409, Body: { "secret": "already exists with value '0nyB_F6XMrNc09maS6qe-DSD73o_AbD9hCq9649SkcNH0VhiImjdOLx4FoWjnB8x'" }

• Database

Cassandra

[guan]

postgres too.

I have the same question.
I want to use shared secret per application to sign all tokens.

[thibaultcha]

A Consumer in Kong is an abstract concept, not necessarily an individual. Why not creating a Consumer that is, in fact, your application?

[thibaultcha]

Considering this answered since no reply was given. Feel free to re-open of open another issue if you have any other concern.

[mohamedrez]

I have the same issue, where I want grant access individuals to use a protected endpoints, at the same time I need to verify the jwt token on another services.

[codeocelot]

I have the same issue. Using the same consumer for all of my users isn't acceptable since it eliminates or severely hampers the usefulness of most of Kong's middleware. How do I rate limit a single user?

[thetrav]

@thibaultcha any chance of getting this one re-opened? I've got the same issue, I'm using keycloak as the JWT provider.

As per @codeocelot I want to use kong's consumer for rate limiting, analaytics and other plugins. Having a single consumer in kong for all apps that use my APIs won't work.

Is there a reason for the unique constraint?

[thetrav]

I was able to satisfy my use case by changing to configuration of the plugin. clientId as the config.key_claim_name instead of iss.

[p0pr0ck5]

Git history doesn't show a defined reason to hold this constraint (it has been present since the initial commit). Need to look into why this was assigned, particularly with acknowledgement to cb9bac0 which references this nature specifically.

[onuryavuz]

@thetrav Could you please describe it in more detail?

I was able to satisfy my use case by changing to configuration of the plugin. clientId as the config.key_claim_name instead of iss.

[thetrav]

I was following some guide which used the issuer of the token as the "key_claim_name", which in this case was always the same value (keycloak, my token provider) which provides keys to multiple different consumers.

Kong uses key_claim_name to map the token to its consumer, so using the clientId claim makes a lot more sense than using the issuer (iss)

I'm actually using Keycloak as the provider for an OpenID Connect solution. I looked at the Kong plugin for OIDC, however it wanted to be the token provider.

[thibaultcha]

#2548 removes the unique constraint on JWT credentials, so this should be resolved. Expect this for a 0.11 release. Thanks!

[ebarault]

hi,
i'm afraid #2548 does not fix it completely, the constraint on key still exists:
key = {type = "string", unique = true, default = utils.random_string},

which causes the following error :

{"key":"already exists with value 'https:\/\/mydomain.auth0.com\/'"}

when using jwt rs256 and trying to configure the same jwt issuer for different consumers.

Anyhow, as per @thetrav 's comment:
"Kong uses key_claim_name to map the token to its consumer, so using the clientId claim makes a lot more sense than using the issuer (iss)"

in the case of auth0, the azp (authorized party) claim should be used.

more generally, unicity constraint could be defined on a composite key, in case of auth0 this would be [iss, azp]

[thibaultcha]

It is currently not possible to remove the unique constraint on key, as it must be a distinct value since we select a JWT Credential based on the given claim (iss or another BTW, this is configurable). JWT Credential that is then mapped to a given Consumer, and not several. To support this use case, you will for now have to create a Kong Consumer (an abstract concept, again) that groups several entities in real life. On the long term, JWT Credentials that can be linked to several Consumer could solve this.