Core concepts and trust boundaries

Nanaade Feature-as-a-Service lets an organization license selected Nanaade capabilities while keeping its own portal and login experience. Understanding the boundaries below prevents the two most common integration mistakes: treating SSO as authorization and treating a tenant credential as a user credential.

The authorization chain

Tenant integration credential
  identifies the organization and verifies the assertion
    ↓
User
  identifies the person in Nanaade
    ↓
TenantMembership
  connects that person to the active tenant and role
    ↓
Entitlements + permissions
  determine the modules and actions available

Every protected request is evaluated in tenant context. A valid signature alone cannot create membership, grant a module, or bypass a permission.

Tenant

A tenant is the licensed organization—for example a university, employer, or partner. It owns lifecycle status, branding, module grants, add-ons, integration configuration, and a configuration version used for cache invalidation.

Example: Northbridge University can receive cohort-management and resume-builder, use its own logo and colors, and launch students at northbridge.nanaade.ai. Another university uses the same Nanaade deployment but has separate data, memberships, configuration, and grants.

User and TenantMembership

A User is the Nanaade account and personal profile. A TenantMembership is the organization-specific relationship that references that user.

| Concern | User | TenantMembership | |---|---|---| | Person's authentication identity | Yes | No | | Organization relationship | No | Yes | | Tenant role and permissions | No | Yes | | Status within a tenant | No | Yes | | External tenant subject | No | Yes |

This separation allows roles and access lifecycle to change without rewriting the person's profile. In v1, one Nanaade user may have only one active sponsored member membership at a time; historical and pending relationships can still exist.

External subject

sub is your permanent identifier for the user, such as usr_10482. On the first successful SSO launch Nanaade can find an unbound active membership by normalized email, then bind sub to it. Future launches use that stable binding.

Good subjects are immutable database identifiers. Bad subjects include email addresses, session IDs, access tokens, names, and values generated at each login.

{
  "sub": "usr_10482",
  "email": "amara@northbridge.edu"
}

If Amara later changes her email, usr_10482 stays the same. If a launch supplies usr_99999 for the already-bound membership, Nanaade returns SSO_SUBJECT_MISMATCH rather than silently taking over the relationship.

Modules, add-ons, and shell features

• A module is a primary product area such as resume-builder.
• An add-on is a separately licensed capability beneath a module, such as career-pathway.skill-gap-analysis.
• A shell feature controls shared portal UI such as portal.notifications.

Every add-on requires its parent. Some modules also depend on data from another module. Nanaade validates these relationships when administrators change grants.

Authentication is not authorization

SSO answers “who is launching and which integration signed this?” Membership answers “does this person actively belong to this tenant?” Entitlements and permissions answer “what may this member use or change?”

For example, a student can have a valid SSO session and active membership but still receive FEATURE_NOT_LICENSED for the AI interviewer when the university has not licensed that module.

Retail versus sponsored access

Retail users access Nanaade independently. Sponsored users receive access through an organization. Tenant grants should never leak into retail context, and one tenant's branding or data must never appear in another tenant's session.