Reader sign-in methods
Embed
<a href="https://forumulate.com/guides/reader-sign-in-methods"><img src="https://forumulate.com/guides/_api/public/orgs/046a9bc0-d530-43ae-9bae-af7945008cda/spaces/36aa4df0-1e95-4cef-8ae9-795169441345/pages/00d4825e-b7ef-42c5-beb6-24015c0c25dd/social-card.svg?v=3e7ae33eec8b" alt="Reader sign-in methods" width="600" height="315"></a>Here's everything you can offer readers, grouped by kind. Turn on as many as you like — each one becomes a button (or a form) on your sign-in card. Every method that talks to an outside provider is bring-your-own: you supply your own app's credentials, so logins are tied to your business, not ours.
Built-in methods (no setup)
These work out of the box — just enable them. There's nothing to bring.
Method | What it is |
|---|---|
Email + password | Classic email and password. Readers set a password and sign in with it. |
Email code | A one-time code emailed to the reader — passwordless. |
Magic link | A one-time sign-in link emailed to the reader — passwordless. |
Passkey | Face ID / Touch ID / security keys (WebAuthn). Phishing-resistant, no password. |
Phone / SMS | A one-time code by text message. |
Social sign-in (OpenID Connect)
These are the "Continue with…" buttons everyone expects. You bring your own app's client ID (and usually a client secret) from that provider so the reader is signing into your app.
Method | You provide |
|---|---|
Client ID + secret | |
Microsoft | Client ID + secret |
Apple | Client ID + secret |
Client ID + secret | |
GitLab | Client ID + secret (and an issuer URL if you self-host GitLab) |
Social sign-in (OAuth2)
Same idea — a "Continue with…" button with your own app credentials — for providers that use OAuth2 rather than OpenID Connect.
Method | You provide |
|---|---|
GitHub | Client ID + secret |
Discord | Client ID + secret |
Client ID + secret |
What about X (Twitter)? X's sign-in doesn't hand back a verified email address, and a reader account needs an email to belong to your community. So X isn't offered as a direct button. If you want X logins, run them through your own identity platform (below), which can collect the email itself.
Enterprise and federated
For company logins and custom identity systems. You bring your identity provider's details.
Method | You provide |
|---|---|
OIDC (any provider) | Issuer URL, client ID, client secret, optional scope — works with any standards-compliant OpenID Connect provider |
SAML | IdP entity ID, IdP SSO URL, IdP certificate |
LDAP | Directory URL and bind credentials |
Kerberos | Realm |
DiscourseConnect | Shared secret + provider URL |
External JWT | A JWKS URL or a shared secret — your app hands readers a signed token and they're in |
Your own identity platform
Method | You provide |
|---|---|
Your own Atlas | Your Atlas frontend API URL + publishable key (+ secret key) |
This is the umbrella option. If you already run your own identity platform, point us at it and readers sign in there. Whatever it supports — passwords, passkeys, every social button, SAML, and more — is instantly available to your readers, all under your own user base, through a single connection. If you want "everything, my way," this is it.
How the methods behave
Signing in creates a member. A reader who signs in with any method becomes a real member of your space and is federated into your user base — they post and react as themselves.
A verified email is the anchor. Methods federate a reader on their verified email, so the same person is the same account no matter which button they used.
Mix freely. Offer email-and-password and Google and your company SSO on the same space. Readers choose.