Sign-in options
The sign-in methods a Context deployment supports, and where in the setup console each one is configured.
Where sign-in is configured
Sign-in is configured in the deployment’s setup console at /setup, which is protected by the deployment’s setup password (set at install time; the console asks for it before showing any settings). Only a holder of the setup password can change sign-in methods; no organization role grants this (see Permissions reference).
The console’s Access section has these pages:
| Page | What it controls |
|---|---|
Authentication (/setup, titled Authentication Settings) | Which sign-in methods are on: Email + Password and Single Sign-On. |
| SSO domains | Which email domains route to an identity provider, and domain verification. |
| Enterprise routing | Email domains that are redirected to another (self-hosted) deployment. |
| Blocked domains | Email domains that cannot create an account or sign in. |
Sign-in methods
| Method | Default | Notes |
|---|---|---|
| Email + Password | On | Optional Require email verification (off by default). |
| Single Sign-On | Off | SAML or OIDC, through one identity provider. Can run alongside Email + Password. |
Both are set on the Authentication Settings page (Configure how users sign in to your deployment.). If you try to turn off the last active method, the console asks Disable all sign-in methods? (No sign-in methods will remain active. This may lock all users out.) and only proceeds if you select Disable anyway.
Google and Apple sign-in are available only when the deployment has been configured with their credentials.
Email + Password
Email + Password lets people sign in with email and password. With Require email verification on, people must verify their email address before they can sign in with a password; when off, password sign-in works without verification. The verification toggle is unavailable while Email + Password is off.
Single Sign-On
Single Sign-On lets people sign in with your identity provider. To set it up:
- On Authentication Settings, in the Single Sign-On card, select Add provider.
- On Choose a protocol, select SAML or OIDC.
- Follow the steps in the console, test the sign-in, and select Turn on.
- Turn on the Single Sign-On toggle. The toggle is available only once a provider is active; turning a provider on does not by itself enable SSO sign-in.
The setup steps for each protocol are:
| Step | SAML | OIDC |
|---|---|---|
| 1 | Provide an Identity Provider Name | Provide an Identity Provider Name |
| 2 | Create a SAML application (Context shows its Service provider metadata URL, Assertion consumer service (ACS) URL and Service provider entity ID) | Create an Application (Context shows its Login redirect URI) |
| 3 | Set Identity Provider Metadata (Metadata URL, recommended, or Manual setup with Identity provider Single Sign-On URL, Identity provider issuer and the signing certificate) | Add Claims |
| 4 | Configure SAML Attributes (id, email, firstName, lastName) | Provide your OIDC Configuration (Client ID, Client Secret, Discovery Endpoint) |
| 5 | Test Single Sign-On | Test Single Sign-On |
| 6 | Confirm test user | Confirm test user |
You can skip the test, but the console warns that the configuration has not been tested and that turning it on may break SSO sign-in for your deployment (Turn on anyway). Keep Email + Password on until a second administrator has confirmed SSO access.
For a full walkthrough with Microsoft Entra ID, see Entra ID SAML.
SSO discovery domains
On SSO domains (SSO discovery domains), you bind an SSO provider to an organization and its email domains, so sign-in emails at those domains route to that organization’s identity provider.
- Email domains are comma-separated. Select Save binding to save them.
- A provider only routes after you select Verify domains to confirm you control its email domains. Verification also lets the provider link sign-ins to existing accounts with matching emails, so only verify domains the organization owns. Verify domains needs a saved organization binding and at least one domain.
- Existing accounts. An SSO sign-in is linked to an existing Context account only when the provider is bound here, its domains are verified, the email’s domain matches, and the account’s own Context email is verified. If any of these is missing, the person sees “SSO sign-in failed” and keeps using their existing sign-in method. SAML sign-ins carry no verified-email claim, so for SAML the domain binding and verification are the only way to link.
- Saving resets verification: verify again after any change. Revoke verification removes it.
Enterprise routing
On Enterprise routing (Enterprise domain routing), you send customers to their own deployment: when someone signs in or signs up with an email at a mapped domain, they are redirected to that customer’s self-hosted deployment instead of authenticating here. Add a row per domain; a customer with several domains is several rows pointing at the same deployment URL. Public email providers (such as gmail.com and outlook.com) are rejected.
Blocked domains
On Blocked domains (Blocked email domains), nobody with an email at a blocked domain, or at any of its subdomains, can create an account, whether by email, Google, SSO or an invitation. People who already have an account at a blocked domain cannot sign in again, but anyone signed in right now stays signed in until their session ends. To cut someone off now, ban the user or revoke their sessions. Public email providers such as gmail.com cannot be blocked.
SCIM provisioning
Context accepts SCIM 2.0 user provisioning from enterprise identity providers at https://<your-context-host>/api/auth/scim/v2/. Each SCIM credential is bound to exactly one organization.
SCIM connections are managed through the admin API, not the setup console, and only by the deployment operator (a platform superadmin). Organization administrators and task API keys cannot manage them.
| Action | Request |
|---|---|
| Create a connection (returns the bearer credential) | POST /api/admin/scim/connections with the organizationId |
| List connections | GET /api/admin/scim/connections?organizationId=<organization-id> |
| Revoke a connection | DELETE /api/admin/scim/connections/<provider-id>?organizationId=<organization-id> |
Other identity providers
A step-by-step guide is available for Microsoft Entra ID over SAML. Step-by-step guides for other identity providers are awaiting source.
Context supports these provider types:
- SAML identity providers (by metadata URL, or manually with the single sign-on URL, issuer and certificate).
- OIDC identity providers (by client ID, client secret and discovery endpoint).
For who can create an account and which organization it joins, see Sign-up and accounts.