Cannot create JWTs with a shared secret.

[onuryavuz]

Summary

I want to sign each JWT with a secret that is shared in all micros. I need this because I want other micros to be able to decode given JWT and extract payload data and work upon it (e.g. user_id field in the payload).

When I try to create a JWT for the first consumer, it works just fine. But when I try to create it for the second consumer I'm getting the following error:

{u'secret': u"already exists with value 'secret'}

I'm not exactly sure but I think KONG/JWT requires unique secret for each consumer to create a JWT. Is it possible to configure JWT plugin properly to be able to use shared secret to sign JWTs?

PS: I'm not entirely sure that using a shared secret is a good practice. If there is a better way to do this please let me know. Thanks!

Steps To Reproduce

1. Create the first consumer.

$ curl -X POST http://kong:8001/consumers \
    --data "username=<USERNAME_FIRST_CONSUMER>" \
    --data "custom_id=<CUSTOM_ID_FIRST_CONSUMER>"

2. Create the second consumer

$ curl -X POST http://kong:8001/consumers \
    --data "username=<USERNAME_SECOND_CONSUMER>" \
    --data "custom_id=<CUSTOM_ID_SECOND_CONSUMER>"

3. Create JWT for the first consumer.

$ curl -X POST http://kong:8001/consumers/{first_consumer_id}/jwt \
    -H "Content-Type: application/x-www-form-urlencoded" \
    --data "secret=<SHARED_SECRET>"

HTTP/1.1 201 Created

{
    "consumer_id": <FIRST_CONSUMER_ID>,
    "created_at": <TIMESTAMP>,
    "id": <ID>,
    "key": <KEY>,
    "secret": <SHARED_SECRET>
}

4. Create JWT for the second consumer with the same secret in the request body.

$ curl -X POST http://kong:8001/consumers/{second_consumer_id}/jwt \
    -H "Content-Type: application/x-www-form-urlencoded" \
    --data "secret=<SHARED_SECRET>"

{u'secret': u"already exists with value 'secret'}

Additional Details & Logs

• Kong version ($ kong version)
  v0.10.2

[p0pr0ck5]

Thanks for the report @onuryavuz. This is expected behavior, given the unique constraint on secret- the question is why. Oauth2 secrets had the same constraint (incorrectly) that was removed in #2447; at the time I believed JWT entries required a unique constraint, but I believe I was incorrect in that assessment. From what I can tell, this secret can be removed safely, though it needs some testing.

Since this was initially opened in #1512, closing this as a dup, but we thank you for the report!

[onuryavuz]

@p0pr0ck5 Thank you. I've just subscribed to #1512.