Customer Portal Identity: Designing SSO, Roles and Account Security Before Build

The hardest portal identity question is rarely, “Which login screen should we use?”

It is usually, “Who is this person allowed to act for?” A purchaser may belong to several legal entities. A dealer principal may invite staff with different authority. An adviser may serve many clients. A former employee may still have an active session. A support agent may need temporary access without impersonating a customer invisibly.

Those are identity, organisation and authorisation decisions. If they are left until development, the team tends to encode assumptions into the database and interface. Changing them later can affect account data, integrations, security controls, support procedures and every protected feature.

Customer portal identity therefore needs its own design workstream. It must connect business relationships to identity proofing, authentication, federation, permissions, tenant isolation, recovery, audit and lifecycle operations. Single sign-on may be part of the answer, but SSO is not the identity model.

This guide provides a practical framework for making those decisions before build. It is general information, not legal or security advice for a specific system; the required controls should be assessed against your data, transactions, users and obligations.

Separate identity proofing, authentication and authorisation

Teams often use “login” to describe three different controls:

Identity proofing: establishing that a person is who they claim to be, to the confidence needed for the service.
Authentication: checking that the person returning to the portal controls the relevant account or authenticator.
Authorisation: deciding what the authenticated person may see or do in a particular context.

NIST Special Publication 800-63-4 treats identity proofing, authentication and federation as related but distinct assurance disciplines. That distinction is useful even when an Australian commercial portal is not required to follow the NIST framework.

A verified email address may be enough to receive a low-risk resource. It may be insufficient to view sensitive records, change payment instructions or bind an organisation to a transaction. Conversely, demanding extensive identity evidence for a low-risk portal can damage adoption and collect more personal information than the service needs.

Match assurance to the action

Do not apply one assurance level to the whole portal. Build an action-risk table:

Action	Potential consequence	Possible controls to assess
View public product documents	Low	No account or low-friction registration
View organisation-specific pricing	Commercial sensitivity	Verified invitation, tenant membership, session controls
Access personal or account records	Privacy impact	Strong authentication, scoped authorisation, audit logging
Invite another user	Expanded access	Role restriction, confirmation and notification
Change bank or payout details	Fraud and financial loss	Step-up authentication, dual control, out-of-band notice
Export a full account dataset	High privacy and commercial impact	Elevated role, recent authentication, logging and alerts

The purpose is not to prescribe controls from a blog. It is to make consequence visible so security, privacy, product and operational owners can decide deliberately.

Model people, organisations and relationships

A consumer account can sometimes be represented as one person and one profile. B2B, membership, dealer and partner portals are usually more complex.

At minimum, distinguish:

a person, with their own identity and authenticators;
an organisation or account, representing the customer entity;
a membership, linking that person to the organisation;
a role or policy, defining permitted actions in that membership; and
a resource, such as an order, site, contract, case or location.

This lets one person hold different roles in different organisations without duplicating their identity. It also lets the business remove a membership when employment changes without destroying the person’s account history.

Define the account hierarchy

Ask how customer relationships actually work:

Can one organisation have subsidiaries, branches or locations?
Is access inherited down the hierarchy, or explicitly granted?
Can users act across several accounts?
Can a reseller see end-customer data, and under what rule?
Who becomes the first administrator for a new organisation?
Can administrators invite peers or only lower-privilege users?
What happens if the only administrator leaves?
Which identifier connects the portal organisation to CRM, ERP or billing systems?

These questions affect data modelling and every permission check. An account hierarchy inferred from an ERP customer number may not match the relationships customers expect to manage online.

Choose an authorisation model consciously

Authentication answers “who”; authorisation answers “may this user perform this action on this resource now?” OWASP’s Authorisation Cheat Sheet recommends least privilege, deny by default and validation on every request. Hiding a button in the interface is not an authorisation control; the server must enforce the decision.

Three patterns commonly appear:

Role-based access control

RBAC assigns permissions to roles such as account administrator, purchaser, finance viewer or support agent. It is easy to explain and can suit stable responsibility groups. It becomes unwieldy when dozens of near-duplicate roles are created for exceptions.

Attribute-based access control

ABAC considers attributes of the person, organisation, resource or context. For example, a regional manager may approve an order only when the branch region matches and the value is below a threshold. It is expressive, but policies and data quality need careful governance.

Relationship-based access control

ReBAC bases decisions on relationships, such as “is adviser for”, “manages location” or “belongs to account”. It can reflect complex networks naturally, but the relationship graph and update rules become security-critical.

Many portals use a combination. The design requirement is not to choose a fashionable acronym. It is to express policies in a form that business owners can validate and developers can test.

Protect tenant boundaries explicitly

In a multi-tenant portal, the most serious authorisation failure may be access to another customer’s records. Every resource request should establish tenant context and verify the relationship, rather than trusting an account identifier supplied by the browser.

Test negative cases systematically: a valid user asking for another tenant’s order, a downgraded user replaying an old link, an administrator changing an identifier, a suspended organisation using an existing token, or an export job running after access has been revoked.

Understand what SSO does and does not solve

Single sign-on lets users authenticate through an identity provider and access connected services without separate credentials. In a workforce environment, one organisation often controls the user directory. Customer identity is more varied: some customers want enterprise federation, others need local accounts, and social login may or may not fit the relationship.

Federation can reduce password handling and let a customer’s IT team control its workforce access. It does not automatically:

establish the right portal organisation;
define a user’s business authority;
remove access when portal-specific eligibility changes;
correct poor recovery or invitation workflows;
prevent tenant authorisation defects; or
decide how non-federated customers sign in.

NIST SP 800-63C-4 describes federation as assertions passed between an identity provider and relying party. The portal still has to validate those assertions, map them to local relationships and enforce its own policies.

Use current protocol guidance

Where OAuth 2.0 is involved, implementation should follow current security guidance rather than old examples. RFC 9700 is the OAuth 2.0 Security Best Current Practice and documents attacks, mitigations and deprecated patterns. OpenID Connect may supply an authentication layer, while OAuth primarily addresses delegated authorisation; treating an access token as an improvised login mechanism creates avoidable risk.

Protocol selection, token storage, redirect handling and session design should be owned by suitably experienced practitioners and reviewed in the context of the actual architecture.

Design authentication as a set of journeys

NIST SP 800-63B-4 covers authenticator and lifecycle requirements, while the Australian Cyber Security Centre’s multi-factor authentication guidance explains the value of using two or more factors. The portal needs to decide where MFA is required, which methods are acceptable and how recovery avoids becoming the weakest path.

Map at least these journeys:

registration or invitation;
first sign-in and organisation linking;
routine sign-in;
MFA enrolment and replacement;
forgotten credential recovery;
lost device or compromised account response;
email or phone change;
elevated or step-up authentication;
account suspension and reactivation; and
closure, offboarding or deletion.

Each journey needs eligibility rules, notifications, rate controls, support procedures, audit events and failure states.

Evaluate passkeys in context

Passkeys are based on WebAuthn and can offer phishing-resistant, public-key authentication. Web Authentication Level 2 is a W3C Recommendation. Adoption still requires product decisions: supported devices and browsers, cross-device journeys, shared-device use, recovery, fallback and the experience for users unable to enrol.

The right approach may be phased. A portal can support modern authenticators while retaining a controlled alternative for cohorts that need it. Avoid leaving a weaker fallback permanently ungoverned.

Treat invitations and recovery as security features

Most identity diagrams show successful login. Operational incidents occur around the edges.

Invitation design should address:

who may invite and to which role;
whether the invited address must match a recognised domain;
how long an invitation remains valid;
what happens when it is forwarded or opened by an existing user;
whether privileged invitations need approval; and
which parties receive a notification.

Recovery needs at least the same rigour as authentication. If a support agent can reset MFA after answering easily researched questions, strong authentication has been undermined. Define evidence, escalation, separation of duties and logging for sensitive recovery. Give users clear notices of important account changes and a way to report them.

Design support access openly

Support teams sometimes need to diagnose what a customer sees. Avoid shared accounts or invisible impersonation. Prefer explicit, time-limited support access with a reason, an initiating staff identity, visible indication, restricted actions and a durable audit record. For high-consequence actions, require the customer to perform or approve the action themselves.

Build lifecycle events across connected systems

Portal access may depend on CRM status, subscription, employment, membership, contract dates or dealer accreditation. Decide which system is authoritative for each attribute and how quickly changes propagate.

Key events include:

a new organisation being created;
a customer changing legal entity or account structure;
a user changing role or location;
an account becoming delinquent, suspended or closed;
an employee leaving a customer;
a merger splitting or combining records; and
a data-retention or deletion process taking effect.

Do not assume SSO offboarding solves all of this. A customer may disable its employee identity while the portal still retains active API tokens, remembered sessions or memberships. Conversely, the portal may need to end access even while the identity provider continues authenticating the person.

Specify logging, monitoring and privacy together

Security logs should support investigation without becoming an uncontrolled store of personal information. The OAIC Guide to Securing Personal Information describes reasonable steps across the information lifecycle, including destruction or de-identification when information is no longer needed.

Define which events matter: failed authentication, enrolment and recovery changes, invitation and role changes, access denials, privileged actions, sensitive exports, token creation and support access. Decide retention, access, alerting, time synchronisation and linkage to incident processes. Avoid logging secrets or unnecessary sensitive payloads.

Privacy and security owners should also examine what identity data is collected, why it is needed, where it travels and how users can exercise applicable rights. Obtain specific professional advice for the portal’s circumstances where required.

Test identity as a policy matrix

Happy-path acceptance tests are inadequate. Create a matrix whose dimensions include user state, organisation state, role, resource relationship, channel, session age and requested action.

Prioritise high-consequence combinations and negative tests:

unauthenticated, invited, active, suspended and closed users;
active, suspended and closed organisations;
own, child, unrelated and transferred resources;
current, expired and revoked sessions;
web, API, export and background jobs; and
ordinary, privileged and support access.

Automation can cover recurring policy checks, but manual security testing and architecture review may also be appropriate. Define remediation expectations, retesting and production monitoring before launch.

What belongs in paid Discovery

Portal identity touches commercial rules, customer operations, privacy, security and connected systems. If the account hierarchy, access policies, identity provider, migration or recovery model is unresolved, a fixed implementation quote is likely to rest on hidden assumptions.

Paid Discovery can map actors, organisations, relationships, protected resources, high-risk actions, authentication journeys, role policies, system-of-record boundaries, exceptions and non-functional requirements. It should produce diagrams, policy matrices and prioritised requirements detailed enough to choose an architecture and estimate delivery responsibly. It is not a free security audit or free portal strategy.

Discovery should also expose organisational decisions the implementation cannot make: who approves new account administrators, who resolves disputed organisation ownership, who supports recovery, and who monitors identity events after go-live.

A pre-build identity decision checklist

Before development commits the data model, confirm that the accountable stakeholders can answer:

Who are the human and machine actors?
What establishes eligibility and, where needed, identity confidence?
What is the organisation and account hierarchy?
Can one person belong to several accounts?
Which authorisation model expresses the real policies?
What is the tenant-isolation rule for every protected resource?
Which users need local login, federation or both?
Where is MFA or step-up authentication required?
How do invitation, recovery, suspension and offboarding work?
Which systems own roles and account status?
What is logged, monitored and retained?
Who operates the service when an identity journey fails?

If several answers are “to be decided during build”, the identity scope is not ready for ordinary implementation.

Frequently asked questions

Is SSO the same as customer identity management?

No. SSO can let a person authenticate through an identity provider, but the portal still needs account linking, organisation membership, permissions, tenant isolation, recovery, lifecycle and audit controls. SSO is one capability inside the identity model.

Should customers use their work identity provider?

Federation can suit enterprise customers that manage their own workforce identities. A portal may still need local accounts for other cohorts and a reliable method to map federated users to portal organisations. Evaluate customer capability, support, contracts and fallback journeys.

What is the difference between authentication and authorisation?

Authentication establishes that the current user controls an account or authenticator. Authorisation decides whether that user may perform a particular action on a particular resource in the present context. Both must be enforced, and a successful login does not imply broad access.

Does every portal need MFA?

The decision should reflect the consequences of account compromise and specific obligations. Many portals should require MFA for privileged or sensitive actions, and some for all users. Method, recovery and accessibility are part of the design, not afterthoughts.

Are passkeys appropriate for a customer portal?

They can provide a strong, user-friendly authentication option, but suitability depends on device support, user cohorts, shared devices, cross-device journeys and recovery. Plan adoption and fallback rather than treating passkeys as a single switch.

How should a portal handle users who belong to several organisations?

Represent the person separately from organisation memberships. Let each membership carry its own role and status, and make the active organisation context unambiguous. Test that changing context cannot expose another tenant’s data.

What happens when a customer’s administrator leaves?

Define a recoverable, auditable transfer process before launch. It may involve another authorised administrator, business verification or a controlled support escalation. Avoid ad hoc resets or retaining former employee access for convenience.

When does portal identity need paid Discovery?

Use paid Discovery when account hierarchies, roles, SSO, integrations, migration, sensitive actions or recovery procedures are not sufficiently defined to choose architecture and price implementation. Identity changes made after build begins can be structurally expensive.

How Emote can help

Emote helps organisations define customer portals around real users, account relationships and operational workflows. Where identity and integration requirements are unresolved, paid Discovery can map the account model, journeys, permissions, data boundaries and delivery risks before technology choices and estimates are finalised.

Identity rarely stands alone; the guide to website integrations to decide before development helps frame the connected-system questions.

Planning a customer portal? Book a meeting with Emote to discuss the account model, journeys and integration boundaries.