Identity Hub

The Identity Hub is Authrim’s core concept for managing user identity. It acts as a central point that aggregates multiple identity sources — social logins, enterprise SSO, passwordless credentials, verifiable credentials — into a single unified identity per user. This page describes the concept, use cases, and key mechanisms.

The Problem

Modern applications face identity fragmentation:

• Multiple login methods — Users may sign in with Google, Microsoft, GitHub, email OTP, or passkeys. Without identity linking, each method creates a separate account.
• Enterprise federation — Organizations use their own IdPs (Okta, Azure AD, Google Workspace). Onboarding each requires custom integration.
• Inconsistent access control — Permissions come from different sources (IdP groups, application roles, organization membership) with no unified evaluation point.
• Progressive trust — A user who signed up with a social login has weaker identity assurance than one who completed KYC or registered a passkey. There is no standard way to model this progression.
• Privacy fragmentation — Personal data is scattered across providers with no central governance for consent or data deletion.

The Identity Hub addresses these challenges by providing a single identity record that links all external and internal identity sources, applies unified policy, and distributes permissions to applications.

Architecture Overview

flowchart TB
    subgraph Sources["Identity Sources"]
        direction LR
        G["Google"]
        M["Microsoft"]
        GH["GitHub / Apple"]
        S["Enterprise SAML"]
        P["Passkeys"]
        E["Email OTP"]
        V["Verifiable Creds"]
    end
    subgraph Federation["Federation Layer"]
        direction LR
        PA["Protocol Adapters
(OIDC, SAML, OAuth)"]
        IS["Identity Stitching"]
        JIT["JIT Provisioning"]
    end
    subgraph Unified["Unified Identity"]
        UR["Unified User Record"]
    end
    Sources --> Federation --> Unified
    UR --> PE["Policy Engine
(RBAC / ABAC / ReBAC)"]
    subgraph Apps["Applications"]
        direction LR
        A1["App A"]
        A2["App B"]
        A3["App C"]
    end
    PE --> Apps

The five layers:

1. Identity Sources — External IdPs, local credentials, and verifiable credentials
2. Federation Layer — Protocol adapters (OIDC, SAML, OAuth 2.0) that normalize claims into a common format, plus identity stitching and JIT provisioning
3. Unified Identity — A single user record with linked external accounts, aggregated claims, and identity assurance level
4. Policy Engine — RBAC, ABAC, and ReBAC evaluation against the unified identity
5. Applications — Receive tokens with embedded permissions and normalized claims

Use Cases

Enterprise SSO Integration

An organization uses Google Workspace for engineering and Microsoft Entra ID for business staff. With the Identity Hub:

• Both IdPs are connected as identity sources
• Users from either IdP are mapped to the same organizational identity
• SAML assertions and OIDC tokens are normalized into unified claims
• Role assignments come from the Identity Hub, not from individual IdPs

This allows a single application to support users from multiple IdPs without IdP-specific logic.

Consumer Social Login

A consumer application offers Google, GitHub, and Apple sign-in. A user who first logs in with Google and later with GitHub (using the same email) should not end up with two accounts.

The Identity Hub handles this through identity stitching — matching accounts by verified email address and linking them to the same user record. The user sees a single account with multiple linked sign-in methods.

B2B SaaS Multi-Tenancy

A SaaS product serves multiple customer organizations, each with their own IdP:

• Acme Corp uses Okta with SAML
• Contoso uses Azure AD with OIDC
• StartupXYZ uses Google Workspace

Each customer’s IdP is connected as a tenant-specific identity source. The Identity Hub:

• Provisions users on first login (JIT provisioning)
• Associates users with the correct organization
• Applies organization-specific role mappings
• Enforces tenant-level access policies

Progressive Identity

Not all identity assurance is created equal. The Identity Hub supports progressive strengthening:

flowchart TB
    L0["Level 0: Anonymous session"]
    L1["Level 1: Social login (Google, GitHub)
email verified by provider"]
    L2["Level 2: Email OTP verification
direct email ownership proof"]
    L3["Level 3: Passkey registration
device-bound cryptographic credential"]
    L4["Level 4: KYC / Verifiable Credential
government-issued identity proof"]
    L0 --> L1 --> L2 --> L3 --> L4

Each level provides stronger identity assurance. Applications can require a minimum assurance level for sensitive operations — for example, requiring Level 3 (passkey) for financial transactions while accepting Level 1 (social login) for content browsing.

Verifiable Credentials Integration

The Identity Hub can accept Verifiable Credentials (VCs) as identity sources through the OpenID for Verifiable Credentials protocols:

• OpenID4VCI — Issuing credentials from the Identity Hub
• OpenID4VP — Accepting credential presentations as identity proof

VCs enable attribute verification without direct IdP integration. For example, a user can present a government-issued age credential to prove they are over 18, without revealing their exact birthdate or name. These verified attributes are added to the unified identity and can be used in ABAC policy evaluation.

Key Concepts

Identity Stitching

When a user authenticates with a new identity source, the Identity Hub checks if the incoming identity can be linked to an existing user:

1. Email match — If the incoming identity has a verified email that matches an existing user, the accounts are linked automatically
2. Explicit linking — Users can manually link additional sign-in methods from their account settings
3. Conflict resolution — If an email is verified by one provider but not another, linking requires explicit user consent

After stitching, the user has a single identity with multiple linked external accounts. Any linked method can be used for subsequent sign-ins.

JIT Provisioning

Just-In-Time (JIT) provisioning creates user accounts on first login. When a user authenticates through a federated IdP for the first time:

1. The Identity Hub checks if a matching user exists (via identity stitching)
2. If no match is found, a new user record is created
3. Claims from the IdP (name, email, groups) are mapped to the user profile
4. Default roles and permissions are assigned based on the IdP mapping configuration
5. The user is fully provisioned and ready to use the application

No pre-provisioning or directory sync is required for basic federation. For advanced scenarios, SCIM provisioning is also supported.

Claims Aggregation

The Identity Hub aggregates claims from multiple sources into a unified profile:

Claim Source	Examples	Trust Level
Social IdP	Name, email, picture	Medium (provider-verified)
Enterprise IdP	Email, groups, department	High (organization-verified)
Self-declared	Display name, preferences	Low (user-provided)
Passkey	Device attestation	High (cryptographic proof)
Verifiable Credential	Age, nationality, qualification	High (issuer-attested)

When claims conflict across sources (e.g., different display names), the Identity Hub applies a configurable precedence order. Higher-trust sources take priority by default.

PII Separation

Personal data collected from identity sources is stored separately from authentication data:

• DB_CORE stores authentication state — user IDs, credential hashes, session references
• DB_PII stores personal data — email, name, address, phone

PII can be partitioned by geography (EU, US, APAC) for data residency compliance. See PII Separation for implementation details.

Unified Authorization

The Identity Hub serves as the foundation for Authrim’s authorization system. Once a unified identity is established, the Policy Engine evaluates access using three complementary models:

Model	Based On	Example
RBAC	Roles assigned to user	admin role grants manage:users permission
ABAC	User/resource/environment attributes	Department = “Engineering” AND time = business hours
ReBAC	Relationships between entities	User is member of Organization that owns Resource

Authorization decisions are embedded in tokens (ID tokens and access tokens) as custom claims. Applications receive the final permission set without needing to query the Identity Hub at runtime.

flowchart TB
    subgraph Hub["Identity Hub"]
        UU["Unified User
(linked accounts)"] --> PE["Policy Engine
(RBAC+ABAC+ReBAC)"] --> TC["Token Claims
(permissions)"]
    end
    TC --> JWT["Signed JWT Token
with permissions"]
    JWT --> A["App A
(verify token)"] & B["App B
(verify token)"] & C["App C
(verify token)"]

This approach moves authorization decisions to the token issuance time rather than request time, reducing runtime latency and eliminating the need for applications to maintain their own permission stores.

Next Steps

• Social Login — Configure social identity providers
• SAML — Enterprise SAML federation
• PII Separation — Database-level PII isolation
• RBAC — Role-based access control configuration
• ABAC — Attribute-based access control policies
• ReBAC — Relationship-based access control with Zanzibar-style tuples