What's single sign-on? It's the idea that you can sign into many websites across the internet using one of your existing credentials, instead of needing to have a password for every site or using Ghost's typical "magic link" approach. Single sign-on is also called SSO. If the account you're using for single sign-on is a 'social' account, then you might also call this "social sign-on".
Ghost doesn't offer this functionality natively. Instead, users enter their email address and then click a link in email to confirm that they're the owner of that address. This can be pretty seamless - the user gets a cookie 🍪 that keeps them logged in for months, and you get confirmation that their email is correct - the gold standard "double opt-in" or "email confirmation".
But maybe that's not what you want. If you'd like your users to log in with an existing "social" account instead, Spectral Web Services offers a "sidecar" for Ghost that accomplishes exactly that. We store your site's information (outside of Ghost), and then when you send your users to a special link (that we provide), they can give permission to share their profile, which allows us to log them in. Emails are still safe to treat confirmed, as long as you're using a social sign-on provider that confirms emails.
You can try out Social Sign On/SSO right here on my site:
There are two major ways to use this service:
1) Quick-start: Enter your Ghost credentials and put a sign-in link on your site. Seriously, that's it. Your users will see a request for permission for "Spectral Web Services", because you're using our provider keys, but they'll get safely sent to YOUR site at the end of the process.
2) White-labelled option: Enter your Ghost credentials AND your client ID and key for each social provider you're going to use. You'll need to set up an account with each provider (directions to follow), but this approach causes your users to see YOUR site name when they're giving permission.
Quick-start is free for sites with fewer than 1000 members (free or paid) and less than $100/month from subscriptions. [Sites that don't use Ghost's paid memberships but are monetized at more than $100/month should do the right thing and choose a paid plan.] If you have more users or more Ghost subscription income than that, please choose a paid plan. White-labelling is only available for paid plans.
Frequently Asked Questions
Does this work for staff users?
Nope. Currently it works only for regular "members", not for logins at /ghost/
How'd you build it?
When you send a website visitor to your site-specific authentication link, they're redirected to the provider (i.e. LinkedIn), where they do the "OAuth2" pattern. They come back to my server with a confirmation code and the email address the provider knows them by. My server talks to your Ghost server to see if you know of a user by the address already. If so, my server gets a magic link and redirects your website visitor back to your site, where Ghost logs them in just like they'd clicked the link in email. If your server doesn't recognize the email address (a brand new member), then my server tells your server to create the user, then sends them to the magic link.
Their browser takes a couple hops, but it's fast enough to be basically invisible to users.
Is this safe?
API keys, secrets, and passwords live on my server, never in the client.
Still, although I can store your secrets encrypted in the database, they're only encrypted, not hashed. (I have to be able to decrypt them to use them to log in your users.)
Is using a password less safe than using an API key?
Here's my take: Most actions that can be taken with an administrator's username and password can also be taken with an API key. An API key lets the holder change the theme, delete users, send emails, make blog posts, create new users, etc. There's very little that an API key can't do that a password can (besides impersonation and weirdly... snippets), because Ghost's API keys aren't really scoped, so they don't offer much better security than passwords. The risk of data leakage is not very different between Ghost keys and passwords, as long as the password is not re-used.
Is either one safe?
I've made several specific choices to include security, including not allowing display of passwords or API keys on the front end, encryption of sensitive fields in the database, and row level security. I've also specifically chosen to run on Netlify and Supabase rather than my own server, because cloud functions reduce the number of potential vectors for attack compared to whole servers.
Safety advice (good everywhere)
Never re-use passwords between sites, and especially not here.
Provide the lowest level of access required for the functions you need. In this specific case, that means giving the Ghost password for an administrator, not the Ghost owner.
What versions of Ghost?
I've tested most extensively with recent versions of Ghost (5.55+), but any 5.x install should work. I'm just making API calls so it's OK if you're a few minor versions off.
Does it work on Ghost Pro? Do I need to modify the core?
Yes, absolutely, and no, definitely not! (In that order.)
It works great on both Ghost Pro and self-hosted sites. If you have something weird in your setup that might be a problem, let's talk!
How do I show these new login links?
Self-hosters could load a different (edited) version of Portal that includes these links, if someone created one. (Ghost Pro users don't have this option.)
Many paid themes already use custom membership pages - if you're comfortable with html, it wouldn't be hard to add a few extra buttons. (See Basho for an example.) There are also example membership pages in the official Starter Theme that could be added to any theme.
Even if you can't edit your theme, you can still make a regular Ghost page with buttons for each sign-in option. Add a little code injection to remove the existing subscribe buttons and put the link to your new sign-in page in your navigation, and you're good to go! (Yes, this works even on Ghost Pro's Starter Plan.)
If you need help customizing your theme or figuring out the code injection, please get in touch!
How often do my Social Sign In users need to sign in?
Once they get authenticated with Ghost, they get the usual six month cookie. So six months. Or until they clear cookies. Or until they user a different browser/computer. The best answer is "not very often, but it depends a lot on your users."
Can I offer both Social Sign On and regular old Magic Links?
Absolutely. Just make sure you provide your users with links for both!
Exactly how many members can I have on that $5/month plan?
If you anticipate more than 10,000 sign-in/sign-up events per month, please touch base so that we can come up with a fair price. (Estimating the most members will sign in at most once a month, if you have fewer than 10k regular members, you're welcome to try out the $5/month plan.)
Can I really use Social Sign In for free?
If you have fewer than 1000 users total and make less than $100 per month from your Ghost site, then YES! You can use it for free. When you cross over that line, we'll send you an email and ask you (very nicely) to upgrade to the $5/month or $50/year plan. Sorry, but we have bills to pay, too!
Sites of any size can also sign up for a free trial of the paid plans. This requires a credit card. You will be billed at the end of the trial period, so make sure you cancel if you don't want to be billed.
What Sign In providers do you support?
Currently (8/2023): LinkedIn, Github, Google, and Amazon.
Don't see your favorite? Please let me know which providers you want.
There will be no Twitter/X/whatever available in the Quick-start. X has decided that Login with Twitter is a premium ($100/month) service. If you'd like to pay that to get your own client key, please let me know and we can set it up!
Can I self host it?
If you'd like to self-host, let's discuss. I'm willing to license for self hosting instead, which has the advantage of letting you control who has access. Note that you'll need some technical skill to get things set up and secured.
Can I use it on in-app browsers?
Magic links work only badly with in-app browsers, because when a mobile user clicks a magic link in email, they typically end up on their devices main browser, not back in the in-app browser (i.e. LinkedIn or Facebook app). Cookies end up set in the wrong place, and things get messy.
Tested combinations (more to come):
LinkedIn SSO with LinkedIn app ✔️ (tested on iOS - and it autocompletes!)
Amazon SSO with LinkedIn app ✔️ (on iOS)
Google SSO with LinkedIn app ❌ (on iOS)
Google SSO with FaceBook app ❌ (on iOS)
Amazon SSO with FaceBook app ✔️ (on iOS)
Ready to try out SSO with Ghost?
Use the button below to try out this site's sign-up page.