Keystatic with Authentication?

[NeeshSamsi]

Is Keystatic planning to add Authentication built into the CMS or maybe integrations with existing solutions? I am looking to build with Keystatic, wondering if I should wait for first party support for authentication or reach for an existing 3rd party solution to protect all /keystatic routes

[simonswiss]

Hey!

Keystatic is deeply integrated with GitHub, and part of that is using GitHub's authentication to determine who can access the /keystatic routes based on repo permissions (write).

Accessing the Keystatic Admin UI (when the storage strategy is set to github) requires users to login with GitHub. Only accounts with write access for the connected repo will be able to see the /keystatic admin routes.

Unless I misunderstand your question — there are no plans to build an authentication layer with Keystatic, since GitHub's auth is that layer already.

[NeeshSamsi]

Ah my bad, I was still playing around in the local mode. I didn't realise the power of the github storage. Makes a lot more sense now

[radenpioneer]

I think it would be wonderful to consider another authentication method, aside of GitHub. It would be useful for publishers without GitHub accounts.

[eyrewiut]

What about plans for other git services such as Bitbucket or Gitlab? If there are not plans for different auth backends then I think it would be nice at least to support other git services...

Personally, being able to use auth would be a big factor for me in considering whether to use keystatic in a professional project (even though the rest is already really great!). Being able to use it with GoTrue (The backend for Netlify's identity service and Supabase's auth service) or something similar would be really ideal. 🥺

I also wonder whether keystatic is abstracted enough from git for use with clients who have no experience with it, but I think that is a seperate discussion and something possibly more dependant on me and who my clients are than the cms itsself.

[JedWatson]

Aside from Simon's answer, there are a couple of threads in the comments from @eyrewiut and @radenpioneer, I'll share our current thinking for all of them, as always very interested in feedback as it helps us shape what we're building.

Other Git Services

At the moment, Keystatic talks directly to either the local filesystem, or GitHub's API. This is behind an abstraction of sorts, so we could build additional integrations down the track with Bitbucket / Gitlab / other source code hosts. It's a matter of priority, right now we're more focused on features than adding more integrations, but if enough people say "I'd love to use it but it has to work with Bitbucket" (or a company wants to sponsor the work?) we will get to it.

Alternative source code hosts would presumably use their identity systems as well.

Separate Auth

We're building out our own auth system (it's actually working, but not ready) as part of our plans for Keystatic Cloud. When ready, it will let you create teams and projects that users can sign into, and we proxy requests to GitHub's API via our (authenticated by you) GitHub App.

There are a few motivations:

• Allowing people without GitHub Accounts (or repository permissions) to use Keystatic; down the track we could also scope which parts of the codebase they can actually read/write through the API
• Integrating with enterprise user management / SSO
• We are planning to do multiplayer editing (think VS Code Live Edit, but in Keystatic) and that means we need our own concept of users and a central proxy to push changes to GitHub (note: not sure when this will happen, but we're really keen on the idea)
• It simplifies setup by letting us manage the GitHub App, you just need to authorise it to access the repo; like Vercel / Netlify / etc.

Publishing changes without using GitHub

We recognise that not everyone who wants to use Keystatic wants to (or can, confidently) use GitHub. It's a lot for a content author to be working in that UI.

It's just an idea at the stage, but conceptually we could build a publishing workflow that actually opens and can merge PRs (or branches) without leaving Keystatic's UI. This might work in combination with the Cloud Auth I mention above, so users can edit content in Keystatic and merge changes without having GitHub accounts / access.

There are a lot of questions to answer before we do this, like... what happens with CI failures? how do approvals work? what about comments? how do we avoid needing to rebuild a meaningful amount of the UI that GitHub already has, and where do you draw that line? etc.

So this isn't short term, but we can imagine it, and will probably build it 🙂

Our goal is to make code-based content management accessible to everyone, and that will eventually need to include people who aren't comfortable with git (or GitHub). For now it sounds like you're thinking about this the right way ("more dependent on me and who my clients are") and we'll work to broaden that group over time.

---

All of these things go together somewhat, and they're all things we've discussed, but right now it's also neat that we can focus on the editing experience and let GitHub worry about the rest (not to mention we're piggybacking a very mature auth system at the moment)

Also, if (when) we launch an integrated auth system or other features that need servers running, that would likely be something we'd sell on a per-user basis to companies, but Keystatic itself will always be free, and there will always be first class options (like GitHub mode) that you can self-host.

One of our inspirations is Storybook; it's a great package you can add to your project, millions of people use it, and you can host/publish it anywhere. When you want to use it for visual regression testing, Chromatic is a great (paid) way to do that, and it helps fund the open source project that everyone can use.

[etmartinkazoo]

One issue I am having is that we have a Team plan with GitHub and to add a collaborator for a client we need to buy a seat. I feel like WordPress' ecosystem really has a great set of options with groups like Flywheel where for $5 ish a month I can have a managed environment. I would happily pay something in the $5 - $10 a month range for the vast majority of my customers who have hybrid static/ssr Astro marketing sites driven by Astro Collections.

I love the work you are all doing and would be happy to be a beta tester for your Cloud option :)