Customer portal single sign-on: identity is not tenant authorization

Use OpenID Connect to authenticate a customer portal user, then make a separate authorization decision inside the portal for tenant membership and record access. Treating a successful sign-in as permission to every account with the same email domain is a cross-customer exposure waiting to happen.

Separate three identities

The identity provider has a subject identifier. The portal has a local user record. The business has an organization or tenant membership. Link them deliberately and review account linking when a customer's email address changes. Email is useful contact data; it should not be the only durable identity key.

Define the trust contract

Use an established OIDC library and the authorization-code flow with PKCE, which RFC 9700 requires for public clients and recommends for confidential clients. Validate issuer, audience, signature, expiry, state and nonce as required by the flow. Restrict redirect URIs. Keep provider secrets server-side; a browser-readable token is not a shortcut to portal authorization.

OIDC subject -> local user -> active tenant membership -> role -> record policy
Sign-in success stops at the second arrow; the rest is application policy.

Plan offboarding and multiple organizations

A consultant may legitimately belong to two customer organizations. Their active tenant must be explicit, and each record query must be scoped to it. When membership is revoked, invalidate sessions or enforce a short enough permission refresh interval for the business risk. Test an already-open tab after revocation.

For a small portal with one organization and no existing customer identity provider, local accounts with strong MFA may be simpler than federated SSO. SSO becomes valuable when customer IT teams need central lifecycle control or several applications share identity.

Invitation and account linking deserve their own design

A customer administrator may invite a colleague before that person has signed in. Bind the invitation to a specific tenant and expiration, then link the provider subject only after controlled acceptance. If the same email later appears under a different provider or a reused account, do not silently merge identities.

For several customer identity providers, record which issuer and subject pair belongs to each local user. One organization's identity administrator should not be able to grant access to a different organization's records merely by asserting an email claim. The portal's membership ledger remains authoritative.

Session and logout behavior

Define idle timeout, maximum session age, token refresh and revocation latency. Logging out of the portal does not necessarily end the identity provider's session, and logging out of the provider may not immediately revoke portal access. Test the behavior with customer security stakeholders rather than assuming a button implies universal sign-out.

When an employee leaves a customer, an automated provisioning signal can speed removal, but it may fail. Keep a manual removal path and periodic access review. A missing membership should deny access even if the external token remains valid.

Do not build a custom OIDC parser or token verifier. Use a maintained library and verify the deployed provider's discovery document and signing-key rotation. Custom code belongs in tenant mapping and business authorization, not in cryptographic protocol implementation.