Requiring staff sign-in through one provider

ProjectSend 2.8.0 adds an option in Settings → Social login to require that your staff sign in through a specific provider — Microsoft, Google, or any other OpenID Connect provider you have already configured. When you remove a staff member’s access in that provider, it takes effect in ProjectSend too: they cannot sign in. Clients are not part of this. They always use their local email and password.

This note is based on ProjectSend 2.8.0 (October 2026).

Why this matters

If your team uses Microsoft 365 or Google Workspace, your identity provider is already where access decisions live. When someone leaves your organisation, you deactivate their account in the directory. Without the sign-in requirement, ProjectSend does not know about that until you disable their account there separately.

With the requirement enabled, a staff member who can no longer authenticate through the chosen provider cannot sign in to ProjectSend at their next attempt. The access decision happens in one place.

Centralising access control also means your existing processes for onboarding, offboarding and role changes work for ProjectSend without extra steps. If your directory already controls access to email, storage and other tools, ProjectSend can join that group. The hardening guide covers the broader set of security settings for a ProjectSend installation.

How accounts get linked to a provider

Before the requirement means anything, your staff’s ProjectSend accounts need to be linked to the provider you plan to require. The link is created automatically — you do not set it up for each account. It happens the first time a staff member signs in through the social sign-in option.

When a staff member clicks “Sign in with Microsoft” or “Sign in with Google”, ProjectSend matches the provider identity to their account by email address. If the email addresses match, the accounts are linked. After that, they can sign in either through the provider or with their local password.

The require-one-provider setting removes the local password option for staff. So any staff member who has never used the social sign-in option will not be linked, and will not be able to sign in after you turn on the requirement.

Before you turn it on

The requirement applies at sign-in. Before you enable it, check the following:

• Staff have signed in through the provider at least once. The link is created the first time a staff member uses the social sign-in option. If a staff member has only ever used a local password, they will be locked out when the requirement is enabled. Check Settings → Users for accounts without a provider link, and ask those staff members to sign in once through the provider before you turn on the requirement.
• You have communicated the change to your staff. The requirement takes effect immediately when you save it. Staff who try to sign in with a local password after that point will not be able to until their account is linked.
• You have a fallback for administrative access. If the only administrator account has not been linked to the provider, make sure you can still reach Settings → Social login to remove the requirement if something goes wrong.

Clients are not part of this setting. They always sign in with their local email and password, and that is not affected by the provider requirement.

Enabling the requirement

Go to Settings → Social login in your ProjectSend admin. The option to require a specific provider for staff is in that section. Choose the provider — Microsoft, Google, or another provider you have already configured — and save. The requirement applies immediately: at their next sign-in, staff who cannot authenticate through the chosen provider will not be let in.

This option was added in ProjectSend 2.8.0. The 2.8.0 release notes describe it in the “New” section. The original request is in issue #1828, opened for teams that use Microsoft 365 as their organisation’s identity source for ProjectSend staff and wanted a way to remove the local password fallback.

Skipping two-factor when your provider already asks

Settings → Social login also has an option to skip ProjectSend’s own two-factor authentication prompt for a specific provider. This is useful when your provider already asks for a second factor during sign-in. Microsoft 365 conditional access policies can require MFA before granting access to any app, and so can Google Workspace’s context-aware access.

The skip option removes ProjectSend’s own prompt for that provider. Your staff still complete the organisation’s authentication flow — including any MFA the provider requires — but ProjectSend does not add another prompt on top of that.

You can configure these two options independently. Requiring the provider without skipping ProjectSend’s two-factor prompt is also valid: staff will authenticate through the provider and then complete ProjectSend’s two-factor prompt.

Questions

If something here does not match what you see in your installation, ask in the Discord server or open an issue on GitHub. The docs live in the app repository, so corrections are welcome as pull requests. Browse other notes in the Security category.