Where can I find `members_public_key` to validate a JWT?

My Goal

I’m building a comments service, and I’d like to integrate with Ghost’s memberships.

When a Ghost member makes a comment on a blog post, I want my service to verify that the user is, in fact, who they say they are.

What I’ve tried

Based on the advice in this post, I’m now able to get a JWT for a logged-in member on a blog.

My understanding is that this JWT is signed by Ghost and certifies that the user is a valid member.

I plan to send that JWT to my server as proof that the user is legit.

To my understanding, I need a public key in order to verify that the JWT is valid. In particular, it needs to be the public key that corresponds to the private key that Ghost used to sign the JWT.

Where I’m stuck

The post I linked to mentions that this public key is called members_public_key. I’ve searched for that term on Ghost’s various Github repos. However, I haven’t been able to determine how I can get this public key for a given site.

Ideally I can get this value without creating much work for the end-user. For example, maybe I can make an API request to their particular ghost site. (e.g.https://myghostblog.com/get/public/key/here). Or maybe it’s an easy value for the user to find in their settings somewhere and copy/paste into a form on my website.

I’ve been digging around my own Ghost site (which is hosted with Ghost Pro), but I haven’t been able to find the public key mentioned in the post I linked to.

Thanks in advance!

1 Like

I think it’s stored in the setting table. I don’t know if that’s made public (you can’t get it via API request if it’s not)

Thanks for the quick reply @vikaspotluri123 :slight_smile:

Any tips on how to determine whether it’s available via API?

My current approach is to try to track the control flow in the code and see where members_public_key ends up in the application. But I’m finding that quite cumbersome, and if you have any tips on speeding up the search, they’d be much appreciated.


You can use the settings API endpoint by watching the network requests that are made by the admin endpoint. The reason I don’t think it’s publicly exposed is because it’s a “core” setting which is not exposed in the API