IntegrAuth Academy
Identity, security and practical AI — free, from zero. Byte-sized lessons, real diagrams, hands-on labs, zero fluff. Two programs, each with its own exam and certificate.
English is hard? Your browser can translate this page into Tamil, Telugu, Kannada, Malayalam or Hindi. Tech words stay in English so you learn the real names.
How?
- Chrome on phone: ⋮ menu → Translate
- Chrome on computer: right-click → Translate to …
- Edge: the translate icon in the address bar
B2B identity — organizations, invites & team roles
Sam's company buys your product for its whole team. Sam is the admin. He must get forty colleagues in, each with the right access, and some insist on their own company login. This is B2B identity: the customer is an organization, not a person. Your goal: model organizations, invites and roles.
- In B2B the customer is an organization (a tenant) that holds many people.
- Roles belong to the org, not to the person's global account.
- An invite ties together the org, the role and the email.
- Each org can bring its own SSO and rules. Prove it owns the domain first.
- The org's own admin manages the org's people.
Customers are organizations
In business-to-consumer (B2C), the account is the human. In business-to-business (B2B), the account is an organization: a container with many members and its own boundary. Sam's company is one customer holding forty people.
So your data model needs a first-class tenant: the organization that sits above the users. Billing, policy, roles and data all attach to the org, not to the first employee who signed up.
a coworking space. A company rents a block of desks. Its own manager hands out key cards to its people. The space owner knows the company, not every employee. Each company's desks, rules and key cards stay separate.
Tenants, members and org roles
A tenant has three parts.
- The organization is the boundary. Its members see only its data.
- Members are the people (and their invites) who belong to it.
- Org-scoped roles say what each member may do inside that org. An Admin manages people and settings. A Member uses the product. A Billing role sees invoices and nothing else.
These are ordinary role-based access control, limited to the tenant (see RBAC, ABAC & ReBAC). Sam's Admin rights never leak into any other org.
Invitations
Nobody wants Sam to make forty passwords by hand. The normal way is an invitation. Sam types a colleague's email and picks a role. Your system emails a one-time invite link. When the colleague clicks it and signs in, they join that org with that role.
The invite ties three things together: which org, which role and which email. So accepting it cannot put someone in the wrong tenant or give them too much power. Pending invites expire.
Sam pastes forty addresses and tags the roles. One is a personal Gmail, but Org A says "company email only", so that invite bounces. Another colleague clicks the link and lands on the company's own login page, because Org A enforces its own SSO.
Every org brings its own rules and login
A B2B org usually wants its own SSO through its own IdP. Your product then sends anyone from that org to the company login. This is home-realm discovery, keyed on the org (or the email domain).
Before you enforce SSO for a domain, make the org prove it owns that domain. The usual proof is a DNS record.
Orgs also carry their own policies: MFA required, only company emails may be invited, session limits. The rules live on the tenant. So Org A can demand hardware keys while Org B stays on email and passkey. Neither affects the other.
Many orgs and delegated admin
Maya runs her own studio (Org B). She also consults for Acme Retail (Org C). She holds different roles in each. This is the personas idea made real: one human, several memberships. Changing her role in Org C must never touch Org B.
The last big saver is delegated administration. The customer's admin manages the customer's users, not you. Sam invites, promotes, suspends and removes his own colleagues, with no ticket to you. So your support team does not become Org A's help desk. Get the tenant model right, or you rebuild when two customers need different policies (see multi-tenancy).
Go deeper: Claim the domain before you trust it
An org often says "everyone with an @sams-co.com email belongs to us". Before you act on that, make the org prove it owns the domain. You give the admin a random value. They publish it as a TXT record in the DNS of the domain. Without this step, anyone could claim a domain. They could force SSO for its users or take over accounts. Also check the domain name exactly. "sams-co.com.evil.example" is not "sams-co.com". After the domain is proven, you can allow auto-join and require SSO for it.
Go deeper: Keep the org in sync with SCIM
Invites are fine for a start, but staff come and go every month. When a person leaves the company, the company's IdP knows at once, and your product should too. SCIM (RFC 7643 and RFC 7644) lets the customer's IdP create, update and remove its members in your product automatically. See SCIM provisioning. Two more rules. Never remove the last admin of an org. Let each org have at least two admins, so one lost account does not lock the company out.
🧪 Interactive lab — enable JavaScript to play with this one.
When an org brings its own SSO, grade its SAML metadata with SAML Scan. It checks certificates, SHA-1 and signature wrapping. Map the whole discovery surface behind their login with Well-Known Scan.