Registration control

Closing sign-up is not one switch. Rakomi exposes one switch per account-creation path, because the paths have different trust models — so “registration is closed” is a statement about a set of settings, not about a single field.

This page is the list of those paths, in the order to set them.

The paths, and the switch that gates each

Path	Switch	Default
Registration mode (tenant-wide ceiling)	signup_mode (open / closed / invite_only) — set from the dashboard Settings page	open
Password / email self-registration	self_registration_enabled	open
Social sign-up — Google, GitHub, Microsoft	google_oauth_allow_signup, github_oauth_allow_signup, microsoft_oauth_allow_signup	open
Social sign-up — every other configurable provider	the provider’s own allow_signup	closed, and the provider must be enabled explicitly first
Anonymous sessions, and their upgrade to a permanent account	the tenant’s anonymous sign-in setting	off
Enterprise SSO — just-in-time provisioning	jit_provisioning_enabled on the connection (optionally narrowed by jit_require_group)	provisions unless set to false
EUDI wallet sign-in	the EUDI setting for the tenant	off
SCIM 2.0 directory sync	administrator-initiated — not gated by any switch on this page; provisioned via the tenant’s own API token, never a stranger’s action	always available when SCIM is configured

SCIM 2.0 (RFC 7643 Core Schema, RFC 7644 Protocol) directory sync is deliberately excluded from every switch above. Every other row in this table gates a path a stranger initiates — someone authenticating against your tenant for the first time. SCIM provisioning is administrator-initiated: your own API token acts, not a stranger, so none of the switches on this page — including a closed registration mode — affect it.

The registration mode

signup_mode is the tenant-wide registration-posture ceiling — open, closed, or invite_only. It is broader than self_registration_enabled, which gates the password/email endpoint alone. The ceiling caps password/email self-registration, both anonymous-session-claim variants, EUDI wallet sign-in, the enterprise-SSO just-in-time fallback — and social sign-up, for every provider, Google, GitHub, Microsoft and Apple as well as every other configurable one.

The per-provider allow_signup switches stay meaningful underneath it: they decide which providers admit new users while the mode is open. They cannot re-open a path the mode has closed. The refusal a stranger sees is not one uniform shape across the paths — treat “was the account created” as the contract, not the specific error envelope of any one flow.

Composing the settings: a per-provider override, if set, wins; otherwise the tenant-wide floor (signup_default) applies — and both are capped by the tenant-wide mode above. If the mode is closed, no per-provider override or floor value re-opens registration until the mode itself changes.

invite_only is a valid value in the API vocabulary, but it is not yet accepted — a write attempt is rejected with a 400. Use closed until then.

A tenant that existed before this feature shipped never explicitly set signup_mode: its value was derived once, at migration time, from its self_registration_enabled setting at that time (true → open, false → closed).

signup_closed_reason is a free-text field visible in the dashboard UI to every admin of the tenant. Do not put personal data about a named third party in it.

self_registration_enabled gates one path, not all of them

It gates the password/email registration endpoint and nothing else. Setting it to false on a tenant whose Google sign-in is enabled leaves Google sign-up open — a stranger with a Google account still gets an account. Every row above is independent of the others.

Closing every path

1. Set self_registration_enabled to false.
2. Set allow_signup to false for every social provider you have enabled. Each configurable provider carries the flag on its own settings.
3. If you use anonymous sessions, turn them off for the tenant. Upgrading an anonymous session into a permanent account is a different flow from self-registration and is not covered by the switches above, and the tenant-level anonymous setting is the control for it. Removing the upgrade step from your own UI is not a substitute — the endpoint stays callable by anything holding an anonymous session token.
4. If you have an enterprise SSO connection, set jit_provisioning_enabled to false on it explicitly. Leaving it unset provisions new users on first successful sign-in, which is usually what an SSO customer wants and is exactly what you do not want while sign-up is closed. jit_require_group narrows provisioning to one directory group if you want it open but bounded.
5. If you have enabled EUDI wallet sign-in, it admits users on a successful presentation. Turn it off for that tenant if closed sign-up is a requirement.

Steps 3–5 cover features that are off unless you turned them on. If you have not enabled them, they are not open paths for you.

Read the effective state back from GET /v1/auth/config, which reports self_registration_enabled alongside the tenant’s enabled providers. The registration mode and floor (signup_mode, signup_default) are not part of that response — read and set them from the dashboard’s Settings page instead; the public API deliberately does not expose the mode.

This list is maintained by hand

Rakomi adds sign-in methods over time, and each new one arrives with its own control. If you operate a tenant where closed sign-up is a hard requirement, re-check this page after upgrading rather than assuming a previously-complete configuration stayed complete.

Existing users always keep signing in

Every switch on this page gates account creation. None of them gates login.

A user who already exists in the tenant signs in normally under a closed sign-up — including the first time they use a social provider, provided the email on the provider account matches theirs. Rakomi attaches the provider to the existing account instead of treating it as a new sign-up. A user who does not exist receives a signup_disabled error on the redirect instead of an account.

That is what makes the common invite-only shape work:

Provision your users up front (directory sync, CSV import, or the admin API), close every path above, and let people sign in with the identity provider your company already uses. Colleagues get in. Everyone else is refused.

Two details to get right before relying on it:

• The match is on the email address. A staff member whose provider account uses a different address than the one you provisioned is a new user as far as Rakomi is concerned, and a closed sign-up refuses them. Provision the address they actually sign in with.
• Provision users as email-verified. An account imported without a verified email is treated as unclaimed, so the first successful social sign-in on that address takes ownership of it. Importing as verified keeps you in control of who owns the account.

Your identity provider is also part of your attack surface

Closing every switch on this page does not close your enterprise SSO connection’s own provisioning surface. If your identity provider allows guest or self-service account creation, and jit_require_group is left unset on the connection, anyone who can create an account in your directory can still be provisioned into your tenant on first sign-in.

This is your identity provider’s own behavior, not Rakomi’s — the boundary is yours to set, and it is not something the product can enforce from this side.

When to use an enterprise connection instead

The recipe above is an allow-list by provisioning: access is bounded by the set of users you created. It is not an allow-list by domain — there is no setting that means “anyone with an @example.com address may sign up, nobody else.”

If that is what you want, use an enterprise connection (SAML or OIDC) rather than social sign-in:

• you map your email domains to the connection, so users at those domains are routed to your identity provider;
• new users are provisioned just-in-time on first successful sign-in, which you can further restrict to a group in your directory;
• the boundary is enforced by your identity provider — someone outside your organisation has nothing to authenticate against at all.

It also revokes correctly: when your directory disables someone, they lose access. A rule that merely matches on the email domain does not, because the address outlives the employment.

See the SAML SSO guide to set one up.

What these switches do not do

• They do not remove an existing user. Closing sign-up affects who can be created.
• They do not disable a provider. A provider with allow_signup set to false stays available for login — that is the point. To take it off the sign-in screen entirely, disable the provider itself.
• They do not apply retroactively. Accounts created before you closed sign-up remain.