Mastering B2B E‑Commerce Permission Design: From SSO to Fine‑Grained Access Control

Permission Scenarios

Client applications include Admin PC portal, Customer PC portal, H5 mobile site, Mini‑Program, Android app, and iOS app.

Login/registration sources: enterprise SSO, Mini‑Program, custom registration pages.

Authentication

- SSO login: user authenticates via the corporate SSO system; on successful authentication a user account is created in the permission system.
- Mini‑Program login: user authenticates through the Mini‑Program; after successful authentication a user account is created.
- Direct registration: user visits a registration page, creates an account and logs in.

Typical SSO login flow (non‑Mini‑Program):

Mini‑Program login flow (official diagram):

Authorization

- Role assignment: super‑admin can assign built‑in or custom roles to users.
- Built‑in roles: e.g., guest and regular member in Mini‑Program; guests have limited access, members gain full permissions after login.
- Super‑admin initialization: system creates a super‑admin role at first launch for subsequent permission configuration.
- Permission configuration: super‑admin can bind roles, resources, and data scopes to user accounts.
- Account disabling: super‑admin can disable an account to block login.

Conceptual Model Design

Design Key Points

Users may log in or register via different platforms (SSO, Mini‑Program, custom pages).

Users are classified as external or internal; each class may have distinct registration and login methods.

Functional permissions: a role determines which menus, pages, buttons, or API endpoints are visible or callable on a given client. Resources (menus, pages, APIs) are the objects protected by these permissions.

Data permissions: each user is granted a data‑level scope that limits the rows or entities the user can read or modify.

Organization hierarchy: the corporate org‑tree defines superior‑subordinate relationships; permissions are often inherited from subordinates to superiors.

Simple scenarios can use classic RBAC (role‑based access control). Complex enterprise scenarios introduce the notion of an “identity”, which groups a set of roles and data permissions. A user can switch identities to obtain different permission sets and may hold multiple identities (e.g., developer, auditor, project manager).

Application segmentation: each front‑end portal (admin, storefront, etc.) maintains its own permission namespace.

Micro‑service architecture: an API Gateway performs unified authentication; downstream services trust the gateway and receive user information via HTTP request headers.

Front‑back separation: the front end stores the JWT or session token in LocalStorage/SessionStorage and queries functional permissions via dedicated APIs to render UI elements. Data permissions are enforced by back‑end services when querying or updating data.

Conclusion

Separating functional permissions from data permissions yields a flexible, extensible permission system. By linking identities, roles, resources, data scopes, and organizational structures, fine‑grained access control is achieved.