Identity Hub
Authrim can connect several sign-in methods and external identity providers to an account, then use that account in application authentication and policy evaluation. “Identity Hub” describes this role; it does not mean all identities with the same email are automatically merged.
Identity sources and accounts
Section titled “Identity sources and accounts”External OIDC/OAuth providers are handled through the bridge; SAML has IdP and SP surfaces. Local methods include passkeys and email codes. The canonical model distinguishes subjects, accounts, account links, profiles, and sensitive values rather than storing everything in one user row.
For example, an organization can configure enterprise SSO while an application also offers local sign-in. The provider configuration, tenant, linking rules, and application policy determine whether a sign-in reaches an existing account or provisions a new one.
Account linking
Section titled “Account linking”The bridge’s identity-stitching implementation first considers explicit linking and existing provider identities. Email-based automatic linking has additional conditions:
- Identity stitching is enabled.
- The provider permits
autoLinkEmail. - The incoming email is verified by the provider.
- The matching local account’s email is also verified.
- The existing provider identity does not conflict with another account.
If an account with the email exists but linking is not permitted, the user is asked to sign in with existing credentials and link the provider afterwards. A matching email string alone is not sufficient. These rules are the bridge path’s behavior, not a blanket promise that every federation protocol uses identical linking logic.
Just-in-time provisioning
Section titled “Just-in-time provisioning”When no account matches, configured JIT provisioning can create an account during the first federated sign-in. Provider and JIT settings control whether provisioning is allowed, whether verified email is required, and how attributes are mapped. Configure role and group mappings explicitly rather than assuming a provider’s claims automatically grant local privileges.
Authentication strength and attribute evidence
Section titled “Authentication strength and attribute evidence”A passkey, email verification, external SSO, and an identity document prove different things. Authrim does not define the earlier illustrative “Level 0–4” ladder as a universal assurance contract. A passkey protects authentication; it does not by itself establish a person’s legal identity. Evaluate assurance requirements through the relevant flow and policy settings.
ar-vc implements credential issuance and presentation routes, including /vci/credential, /vp/authorize, and /vp/response, plus attribute-verification paths. These require their own configuration, trusted issuers, accepted formats, and validation rules. Their existence is not a claim that every wallet, credential type, or attribute can be used as a primary login method.
Authorization
Section titled “Authorization”| Model | Typical input |
|---|---|
| RBAC | Roles and assigned permissions |
| ABAC | Subject, resource, and environmental attributes |
| ReBAC | Relationships between subjects, organizations, and resources |
Applications can use configured token claims and/or runtime policy evaluation. A token reflects information at issuance; it does not automatically reflect later permission changes. Choose online checks and token lifetimes according to the operation’s needs. Do not assume every policy result appears in every ID token and access token.
Privacy boundaries
Section titled “Privacy boundaries”Core stores account state and references; PII holds sensitive values and linked identifiers. Field classification and the calling path determine which values remain inline. Lookup resolves the account’s actual stores. PII Separation describes the limits of this separation and the coordinated deletion flow.
Useful next steps: Social Login, SAML, RBAC, ABAC, and ReBAC.