Configure Google SSO for self-hosted deployment

[myrfnrz]

I have configured SSO with Google for organization and already able to be directed to Google consent screen. However, screen page was appearing error with detail "error=default_role_required".

After some re-check, I am emptying the default role field that require org-level role and all my role is partner-level. I can't find menu to add org-level role and it makes SSO login always failed.

Actually, How to configure correct Google SSO for organization here?

[ToddHebebrand]

Thanks for the detail — the empty role field is the whole story, and this is our bug, not a misconfiguration on your side. You've hit a dead end that has no way out through the UI.

What the error means. default_role_required comes from apps/api/src/routes/sso.ts:2588. It fires when a provider has auto-provisioning on but no valid defaultRoleId: with JIT enabled, a first-time SSO user has no account yet, so the callback needs a role to create them with. No role, no provisioning, and the login is refused rather than creating a permission-less user.

Why the picker is empty for you. Two independent filters intersect badly for an org-axis provider:

apps/web/src/components/settings/SsoProviderForm.tsx:154-159 — for an organization provider the dropdown shows roles where scope !== 'partner' and isSystem is false. The built-in Org Admin / Org Technician / Org Viewer are deliberately excluded: a system role has NULL org_id and partner_id, so the JIT path could never resolve it and the API would reject it at sso.ts:465 anyway. Offering them would just move the failure later.

So the field needs a custom, non-system, organization-scoped role. And that is the part you cannot create:

apps/api/src/routes/roles.ts:92-98 — the roles API derives its scope purely from your session token. A partner-scoped session always resolves to { scope: 'partner' }, so every role you create through Settings → Roles is partner-scoped. There is no target-organization selector, and no other surface creates roles.

A partner admin therefore cannot create the one kind of role an org-axis SSO provider requires. That's the dead end, and clearing the field to get past the form is exactly why every login then fails.

Two workarounds, both verified against the code paths, neither pretty.

The direct one: get an organization-scoped session and create the role from there. Invite a user into the organization under Settings → Users, give them the built-in Org Admin role, sign in as that user, and create a custom organization role (any name, whatever permissions you want new SSO users to land with). Your partner admin can then select it in the SSO provider form, because the role now exists with a real org_id.

The other: turn auto-provisioning off. With autoProvision false the callback returns user_not_found instead of requiring a default role (sso.ts:2582), and SSO logs in users who already exist. Note the account-matching rule at sso.ts:2560-2567 — an existing account is only linked if it has no password set and no other provider linked, so this suits pre-created SSO-only accounts and will not attach to an account someone already has a password on.

One thing I have not verified: whether the partner axis has the same trap. Partner-wide providers don't JIT at all — sso.ts:2576 returns invite_required — so default_role_required shouldn't be reachable there. I haven't tested it, so if you see it on a partner-wide provider, say so, because that would be a different bug.

Filed as #3524 to fix properly. The right fix is letting a partner admin create a role scoped to a chosen organization; the dropdown filter is correct as written and shouldn't change.

[myrfnrz]

Thanks for digging into the code and explaining the root cause—that clarifies everything, and I appreciate you filing #3524 for this.

For now, we'll turn off auto-provisioning and pre-create the user accounts manually as a temporary workaround. Thanks for getting back to me so quickly!

[ToddHebebrand]

Closing this out — the root cause is tracked in #3524 (a provider saved without a default role leaves auto-provisioning with no way out through the UI), and you have a working path in the meantime with auto-provisioning off and accounts pre-created.

Worth noting that #3577 has since landed, letting a partner admin create and manage org-scoped roles — which removes one of the ways you could get stuck here. Reopen or start a new thread if the pre-created-accounts workaround gives you trouble.