Individual accounts linked to an organization are a useful starting point for business portals: actions can be attributed and one person’s access can be withdrawn. Single sign-on (SSO) becomes useful when customer organizations have an identity provider and a team responsible for operating it. SSO does not replace application permissions or customer-data isolation.
Separate people, organizations and memberships
If several employees share a password, you cannot reliably establish who downloaded a document or changed a request. Removing a departing employee also disrupts everyone else. Multi-factor authentication and account recovery become harder to assign. A narrowly controlled service account is a different requirement, not a reason to give human users a shared identity.
Model the person separately from their organization memberships. Someone may legitimately work with more than one customer organization, but switching between them should be deliberate and authorized. Do not trust an organization identifier supplied by the browser without checking membership for the requested action.
Choose by operating requirements
| Login approach | Appropriate situation | Questions to settle |
|---|---|---|
| Portal-managed individual account | Customer has no central identity service | Verification, recovery and additional authentication |
| Customer organization SSO | Customer operates an identity provider | Provider trust, role mapping, revocation and outages |
| Short-lived sign-in link | A bounded journey whose risk policy permits it | Expiry, one-time use and mailbox security |
A company email domain alone should not grant administrator rights. Define who can invite members, how the first organization administrator is verified and what happens when domains change or organizations merge. For a federated protocol, verify the issuer, intended audience and other protocol-specific security requirements using maintained libraries and the provider’s current documentation.
Design departure before onboarding
Write down what revocation does to memberships, active sessions, invitations and document links. Disabling a person at the identity provider may not immediately end an existing portal session. Establish and test the application’s revalidation and session-revocation behavior instead of promising instant removal without end-to-end evidence.
Test a revoked user with an already-open tab as well as a fresh login. Check that a saved document URL cannot bypass the revoked membership. Keep an audit trail of the decision and outcome without recording session tokens or passwords.
Include recovery and ownership in the estimate
Who restores access if the customer loses control of its identity provider? Emergency access must have identity verification, limited authority and an auditable review process. It must not become a permanent bypass. Do not publish sensitive recovery procedures on a marketing page.
Before pricing SSO, confirm supported protocols, any per-organization charges, who supplies the test environment, how roles are updated and who accepts the final behavior. A “sign in with your company” button is only the visible part of the work.
Scope the decision through customer portal development, systems integration and a written project brief. Choose the least complex approach that satisfies the actual access policy.
Sources and editorial status
- OpenID Connect Core.
- OWASP Session Management Cheat Sheet.
- Original contribution: the operating-choice matrix and access-revocation checklist.
