# Ghost JWT question, possible bug? **URL:** \ **Category:** Developer help\ **Created:** [May 19, 2022, 1:12am UTC](https://forum.ghost.org/t/ghost-jwt-question-possible-bug/30210 "2022-05-19T01:12:24Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![elijahsgh](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.ghost.org/elijahsgh/32/6949_2.png) [@elijahsgh](https://forum.ghost.org/u/elijahsgh)\ **Post date:** [May 19, 2022, 1:12am UTC](https://forum.ghost.org/t/ghost-jwt-question-possible-bug/30210/1 "2022-05-19T01:12:24Z")
I was working with getting a jwt from ghost to authorize access to a Members-Only enhanced search. From previous posts, etc, the workflow is the user signs in, then we send a GET request to members/api/session, and then submit that JWT. This works fine _except…_ The JWT provided by Ghost seems to have an error. The `kid` claim is in the body instead of the header where it is expected. `kid` is an optional JWS header parameter per [RFC](https://www.rfc-editor.org/rfc/rfc7515#section-4.1.4) If I’m confused then please let me know but this seems wrong and breaks compatibility with libraries that expect to load the `kid` from the header to match to the JWKS that Ghost publishes. Python example (pyjwt) ```auto jwks_client = jwt.PyJWKClient('/members/.well-known/jwks.json') jwks_client.get_signing_key_from_jwt(current_jwt) ``` ```auto jwt.exceptions.PyJWKClientError: Unable to find a signing key that matches: "None" ``` On a side note I don’t see any sort of membership tiers in here. Are there? Mine do not seem to be showing up. It would be really amazing if they did! ---
**Author:** ![Hannah](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.ghost.org/hannah/32/22_2.png) [@Hannah](https://forum.ghost.org/u/Hannah)\ **Post date:** [May 19, 2022, 3:06pm UTC](https://forum.ghost.org/t/ghost-jwt-question-possible-bug/30210/2 "2022-05-19T15:06:50Z")
Hey @elijahsgh you’re right that’s absolutely a bug. We’ve got it on our radar to fix now :) ---
**Author:** ![elijahsgh](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.ghost.org/elijahsgh/32/6949_2.png) [@elijahsgh](https://forum.ghost.org/u/elijahsgh)\ **Post date:** [May 19, 2022, 3:10pm UTC](https://forum.ghost.org/t/ghost-jwt-question-possible-bug/30210/3 "2022-05-19T15:10:03Z")
Thanks so much! On the possible enhancement side what about a “Memberships” claim? 🙂 I can probably fetch this through the Admin API from the downstream service but having them in the JWT would be awesome! ---
**Author:** ![naz](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.ghost.org/naz/32/30666_2.png) [@naz](https://forum.ghost.org/u/naz)\ **Post date:** [May 20, 2022, 8:16am UTC](https://forum.ghost.org/t/ghost-jwt-question-possible-bug/30210/4 "2022-05-20T08:16:48Z")
Hey @elijahsgh 👋 Got a fix prepped for this issue [here](https://github.com/TryGhost/Ghost/pull/14869). Wanted to note that based on a quick glance into [the python lib](https://github.com/jpadilla/pyjwt/blob/675fa10db578886ee6cfd1df688236f69560ced4/jwt/jwks_client.py#L32) to process signing keys, it looks like it wasn’t able to find the correct key as the `use: "sig"` was missing from the payload. I’ve added both the `use` property in the response body and the `kid` header to make sure more clients have easy time working with the endpoint. Can you please verify it works for you? ---
**Author:** ![elijahsgh](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.ghost.org/elijahsgh/32/6949_2.png) [@elijahsgh](https://forum.ghost.org/u/elijahsgh)\ **Post date:** [May 20, 2022, 4:54pm UTC](https://forum.ghost.org/t/ghost-jwt-question-possible-bug/30210/5 "2022-05-20T16:54:50Z")
Hi naz! Unfortunately this is not a solution. The modifications in the link alter `/ghost/.well-known/jwks.json` but I was specifically working with `/members/.well-known/jwks.json`. I did try your branch and could verify that the changes altered the ghost path jwks.json. The core problem is the actual JWT (not the JWKS) is missing the `kid`. I made a PR here: [Fix kid missing from JWT header by elijahsgh · Pull Request #401 · TryGhost/Members · GitHub](https://github.com/TryGhost/Members/pull/401/files) I don’t expect that to be merged. It’s just an example 🙂 pyjwt test after the change above: ```auto >>> jwks_client = jwt.PyJWKClient('http://localhost:2368/members/.well-known/jwks.json') >>> jwks_client.get_signing_key_from_jwt(current_jwt).key_id 'ygdnhQI-mtXEYF3MuMYto_sIDsBtU8bFdEFr6Sza6ss' ``` ---
**Author:** ![elijahsgh](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.ghost.org/elijahsgh/32/6949_2.png) [@elijahsgh](https://forum.ghost.org/u/elijahsgh)\ **Post date:** [May 23, 2022, 9:40pm UTC](https://forum.ghost.org/t/ghost-jwt-question-possible-bug/30210/6 "2022-05-23T21:40:26Z")
Hey hey I saw this today! 🙂 > > > refs https://github.com/TryGhost/Team/issues/1640 > closes https://github.com/TryG…host/Members/pull/401/ > refs https://forum.ghost.org/t/ghost-jwt-question-possible-bug/30210 > > \- Without \`keyid\` parameter some of the clien libraries were not able to match the signin key to verify JWT > \- Missing \`keyid\` parameter allows to indicate the key used to secure JWS (as per https://www.rfc-editor.org/rfc/rfc7515#section-4.1.4) and resolves the automatic matching issue on the client. > \- The \`kid\` parameter was left in claims to avoid accidental breaking changes. Thanks @naz 🥳 Any predictions on when this might be in either Ghost 4 or 5? I was thinking of upgrading to Ghost 5 today… can I/should I override the members version during `ghost install`? ---
**Author:** ![naz](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.ghost.org/naz/32/30666_2.png) [@naz](https://forum.ghost.org/u/naz)\ **Post date:** [May 24, 2022, 5:28am UTC](https://forum.ghost.org/t/ghost-jwt-question-possible-bug/30210/7 "2022-05-24T05:28:56Z")
Yeah, the change has [landed in main](https://github.com/TryGhost/Ghost/commit/fcc9daf5494f515fe1293a2a1cce065960c41a89) just now 😜 Yet another reason to migrate to 5.x! I think ghost install, if you are on the latest ghost-cli version, should be installing 5.0 by default. We have a bug if it’s not!