Using Staff Access Tokens over Admin API Keys

When we discuss in another topic, I thought leveraging Staff Access Tokens more over Admin API key when we use external tools/service, would make more sense. Because Admin API keys don’t have any restriction. If an external service that has admin api keys suffers a data breach, then your site is in a big danger.

Until we get more fine-grained permissions for custom integrations, for sharing Admin API keys with external tools, a safer approach would be:

If external service doesn’t need any system level access and only need to access to your all posts/pages:

  1. Create a staff account with “Editor” role (which is the one that can see all posts but not site settings). Since accepting with an email is required, you can use one of your emails or an anonymous email address and accept the invitation.
  2. Give Staff Access Token of this user to external service instead of creating Admin API Key.

If external service need to have one-time access to your system resources (like creating webhooks):

  1. Create a staff account as described above.
  2. Create an admin token, share with the app, initiate the process.
  3. Update the key you shared with external tool with the Staff Access Token of the user you just created.
  4. Regenerate the Admin API key that you created for the external tool. Deleting the key will also delete webhooks it’s created. But regenerating will be safe enough.

If external service need to see/update your system resources continuously:

Then, there is nothing to do other than sharing Admin API Key.


Editor Role user can see, change or delete any posts/pages in your Ghost site. But it’s still more restrictive than an Admin API Key.

What do you think? Would that work? If this is already a common practice that I don’t know, sorry for the noise :smiley:

1 Like

I had a write-up about this on my to-blog list for this month, but you’ve gone and scooped me. ;)

Consider contributor staff tokens also. They have read access to most non-admin endpoints, and can create post drafts, but mostly behave like read-only tokens. (Note that they can read ALL posts, not just ones assigned to that contributor, and that includes drafts.) If you need just a little more than what you’d get with a content api key, they can be just what you need.

And if you’d like to avoid actually creating the user through Ghost’s flow (and needing to click an emailed invite), feel free to use this instead:

1 Like

I tried to login Ghost admin with a Contributor staff, and noticed that it can’t see anything other than its own posts. Documentation also mention like so, so I thought Editor is the minimum role we can use. Am I wrong?

The API endpoint is not as locked down as the behavior of the admin panel.

1 Like

Sorry for that, I missed it. But I think it still worths a detailed article :blush:

1 Like