Client portal adoption dies on passwords. A client contact who has to remember a separate password for your portal will email your service desk instead, and the portal you built to reduce ticket noise quietly becomes an unused feature.

Client portal SSO removes the password entirely. Portal users sign in with the Microsoft account they already use every day, and their access is decided by a group in their own directory.

Client portal SSO is available on Pro.

How it works

Each Entra tenant you map is scoped to a single client. That boundary is the whole security model: a user authenticating from Contoso's directory can only ever land in Contoso's portal, never in another client's.

Within that mapping, an Entra access group decides who gets in:

A user in the group signs in and a portal user is provisioned for them.
A user removed from the group has their portal account deactivated.

The client's IT administrator manages their own access list, using the group membership tools they already know. Nobody has to email your service desk to add a starter or remove a leaver.

What the client sees

Figure 1: The portal sign-in page. SSO sits alongside password sign-in rather than replacing it.

Sign in with Microsoft appears next to the standard email-and-password form. Portal users who are not covered by an SSO mapping continue to sign in with a password, so you can enable SSO for one client without disrupting any other.

Clients using custom portal domains sign in through the same path — the custom domain does not need separate SSO configuration.

Configuration

Portal SSO settings live in Settings > Security > Single Sign-On, below the internal SSO configuration.

Figure 2: Workspace-level portal SSO defaults. Individual client mappings can override the role.

MSP workspace default client portal role

The role assigned to newly provisioned portal users in built-in mode, when a client mapping does not override it. User is the usual default.

Set this deliberately. Every portal user provisioned automatically gets this role, so it should be your least-privileged portal role, not your most convenient one. Clients needing broader portal rights — billing visibility, for example — should get them through a mapping override or an explicit change, not through a generous default.

Client portal Entra provisioning mode

Three modes control what happens when Entra sync sees a user who should have portal access:

Mode	Behaviour
Disabled	Entra sync never creates or deactivates portal users
Built-in	AlgaPSA provisions and deactivates portal users automatically
Workflow-managed	Provisioning is delegated to a workflow

The workspace setting is a default. Each tenant mapping can override it, so a client with unusual onboarding requirements can run workflow-managed provisioning while everyone else runs built-in.

Choose workflow-managed when provisioning needs to do more than create a user — notify an account manager, apply a client-specific role by job title, or record the event in an external system.

Auto-link client portal users

When enabled, a portal user whose email matches an SSO identity is linked to it automatically at sign-in. This is what lets you switch an existing password-based portal client to SSO without re-inviting every contact.

Internal and client auto-linking are separate switches. Turning on auto-linking for your own staff does not turn it on for client contacts, which is a distinction worth keeping — the risk profile of automatically linking an identity from a client's directory is not the same as linking one from your own.

Deactivate Entra-managed users on entitlement removal

When enabled, losing the access-group entitlement deactivates the portal account. Leave this on unless you have a specific reason not to — it is the half of the lifecycle that actually closes access when someone leaves the client.

The broad-group warning

When you choose an access group, AlgaPSA checks how many people it contains relative to the directory. If the group is broad enough that it would hand your entire client directory a portal seat, you get a warning before saving.

The mistake this catches is picking All Users because it was the first group in the list. That works, provisions everyone, and consumes portal seats for people who will never sign in. Scope the group to the contacts who actually need portal access.

Inviting a user with SSO pre-linked

Portal invitations can pre-link an Entra identity. The invited contact clicks the invitation, authenticates with Microsoft, and lands in the portal — they never set a password, because there is no password to set.

This is the cleanest onboarding path for a new client contact and avoids the "set a password you will use twice a year and then reset" cycle that makes portals unpopular.

See inviting clients to the portal for the invitation flow.

Rollout order

Confirm the client's Entra tenant ID with their IT contact.
Ask them to create — or nominate — a group for portal access.
Map the tenant to the client in AlgaPSA and select the group.
Read the broad-group warning if one appears, and narrow the group if it is right.
Set the provisioning mode and default role for the mapping.
Enable auto-linking so existing portal users attach to their identities on next sign-in.
Test with one contact before telling the client it is live.

Troubleshooting

Symptom	Likely cause
User signs in but sees no portal	Not in the access group, or the mapping is scoped to a different client
Portal user created with wrong role	Workspace default role is too broad, or the mapping override is unset
Existing user prompted for a password after SSO is enabled	Auto-link for client portal users is off
User removed from group still has access	Deactivate-on-entitlement-removal is off, or sync has not run
Sign-in loops back to the login page on a custom domain	Confirm the custom domain is fully configured; see custom domain setup

Navigation

13.9. Let Client Portal Users Sign In with Their Own Microsoft Accounts