Single Sign-On (OIDC)

Let your team sign in to Mixpost with your company identity provider through OpenID Connect (OIDC). Available in Mixpost Pro and Enterprise.

Overview

With single sign-on enabled, your login page shows a Sign in with … button next to (or instead of) the email and password form. Mixpost supports:

• Keycloak
• Authentik
• Okta — through the Generic OIDC provider
• Generic OIDC — any provider that implements OpenID Connect discovery (Auth0, Azure AD / Entra ID, Google Workspace, and others)

Beyond signing in, Mixpost can create accounts automatically on first sign-in (just-in-time provisioning) and keep workspace access, roles, and administrator status in sync with the groups your identity provider reports.

Configure Single Sign-On in Mixpost

Navigate to the User Menu at the bottom left, click Admin Console, go to Settings, and open the Single Sign-On tab.

Setting	Description
Enable single sign-on	Shows the single sign-on button on the login page.
Identity provider	The software running your identity provider: Keycloak, Authentik, or Generic OIDC.
Issuer URL	Base URL of your identity provider. Mixpost reads the OpenID configuration from <issuer>/.well-known/openid-configuration.
Client ID / Secret	The credentials of the OIDC client you created in your identity provider. Stored encrypted.
Redirect URI	Read-only. Copy this address into the allowed redirect URIs of your identity provider client.
Scopes	Space-separated scopes requested from the identity provider. The default openid profile email is right for most setups.
Button label	Text shown on the login button. Leave empty to use the provider name.

After saving, click Test connection. Mixpost fetches the OpenID configuration from your issuer and lists the discovered endpoints, or shows the exact error returned by the identity provider. The test always runs against the last saved configuration, so save first.

Sign-in options

• Allow password login — turn this off to require single sign-on for everyone. The email and password form disappears from the login page, and password sign-in is also rejected server-side. See break-glass access before turning this off.
• Require a verified email — reject sign-ins when the identity provider reports an unverified email address.

User provisioning

New users controls what happens when someone signs in through SSO without an existing Mixpost account:

• Only sign in existing users (default) — the sign-in is matched against existing Mixpost users by email address. On the first successful sign-in the identity is linked permanently (provider + subject), so later sign-ins keep working even if the email changes on either side. Unknown users are rejected.
• Create an account automatically — unknown users get a Mixpost account on first sign-in (just-in-time provisioning). The account has no usable password; access is controlled entirely by the identity provider.

When automatic creation is enabled, you can also configure:

• Allowed email domains — a comma-separated list. Accounts are only created automatically for these domains. Leave empty to allow any domain. Existing users are not affected by this list.
• Default workspace / Default role — the workspace and role assigned to automatically created users when no group mapping matches. An automatically created user must end up with at least one workspace, otherwise their sign-in is refused.

Role mapping

Mixpost can read the groups a user belongs to from a token claim and translate them into workspace access:

• Groups claim — the name of the claim holding the user's groups (groups by default). Leave empty to turn off role mapping. Your identity provider must be configured to include this claim — see the Keycloak and Authentik guides.
• Administrator group — members of this group become Mixpost administrators; users removed from it lose administrator status on their next sign-in. Mixpost never demotes the last remaining administrator, so you cannot lock yourself out of the Admin Console this way.
• Group mappings — each row grants members of an identity provider group access to a workspace with a role (Admin, Member, or Viewer) and, optionally, post-approval permission. Select All workspaces to apply a rule to every workspace at once. When several rules match the same workspace, the highest role wins and approval permission is granted if any matching rule grants it.
• Update access on every sign-in — keeps workspace access, roles, and administrator status in sync with the identity provider on each sign-in. When off, groups are only applied when an account is created.

Which workspaces does Mixpost manage?

Only workspaces that appear in your group mapping rules (or every workspace, if you use All workspaces) are managed by SSO — users are added, updated, and removed from those based on their groups. Workspaces that are not listed are never touched, so memberships you assign manually stay intact.

Offboarding

OpenID Connect is a sign-in protocol: your identity provider is asked for approval every time someone signs in, but it cannot notify Mixpost when an account is deleted. Offboarding is therefore a two-step process:

1. Delete (or disable) the user in your identity provider. From that moment the user cannot sign in to Mixpost through SSO. With Allow password login turned off, they cannot sign in at all.
2. Delete the user in Mixpost (Admin Console → Users) to remove their account and workspace memberships.

Sessions that were already open expire naturally.

tip

If you prefer not to delete the account in the identity provider, removing the user from your mapped groups has a similar effect: on their next sign-in they lose access to every managed workspace.

Break-glass access

Single sign-on is controlled from the dashboard, but one environment variable overrides it:

MIXPOST_SSO=false

If your identity provider ever becomes unavailable while Allow password login is off — leaving everyone, including administrators, unable to sign in — set MIXPOST_SSO=false in your environment and restart the application. Password login is restored immediately, without touching your saved SSO configuration. Remove the variable (or set it to true) once the identity provider is back.

Troubleshooting

• Test connection fails — verify the Issuer URL responds at <issuer>/.well-known/openid-configuration, and that the URL is reachable from the server running Mixpost (not just from your browser).
• The identity provider rejects the redirect — the Redirect URI shown in Mixpost must be listed, character for character, in the allowed redirect URIs of your OIDC client.
• "No account matches your identity" — provisioning is set to Only sign in existing users and no Mixpost user has that email address. Create the user first, or switch to automatic account creation.
• "Your email address is not verified" — the identity provider reports the email as unverified. Verify it there, or turn off Require a verified email.
• Group mappings have no effect — the groups claim is missing from the tokens. Configure your identity provider to include it (see the provider guides) and check the claim name matches the Groups claim setting.