Identity Integration

Mandaitor integrates with multiple identity providers to verify who is creating and using mandates. The identity layer answers a foundational question: "Who is this person?" — so that Mandaitor can then answer: "May this person act on behalf of another?"

Supported Identity Providers

Provider	Protocol	Use Case	Status
EUDI Wallet	OpenID4VP	eIDAS 2.0 European Digital Identity	Available
Auth0	OAuth 2.0 / OIDC	Customer-facing apps (B2C/B2B SaaS)	Available
Okta	OAuth 2.0 / OIDC	Workforce identity (enterprises)	Available
Microsoft Entra ID	OAuth 2.0 / OIDC	Enterprise identity (Microsoft ecosystem)	Available
Google Cloud Identity	OAuth 2.0 / OIDC	Google Workspace / consumer accounts	Available
AWS IAM Identity Center	OAuth 2.0 / OIDC	AWS SSO workforce identity	Available
Generic OIDC	OIDC	Keycloak, PingIdentity, ForgeRock, etc.	Available
AWS Cognito	OAuth 2.0 / OIDC	Platform admin & tenant authentication	Built-in

How It Works

Mandaitor uses an Identity Provider Abstraction Layer (IPAL) that normalizes identity claims from any provider into a canonical ResolvedIdentity. This means:

1. A mandate created via EUDI Wallet can be verified by a service using Auth0 tokens — if the identities are linked.
2. An AI agent authenticated via Entra ID can act on behalf of a user who verified with Okta — through the token exchange flow.
3. All identity verification events are recorded in the audit trail, regardless of provider.

Provider Detection

When a token arrives at the Mandaitor API, the authorizer detects the provider automatically:

Token Format	Detected Provider
Bearer tnt_xxx:mk_test_xxx	API Key
Bearer eudi_session:xxx	EUDI Wallet
JWT with cognito-idp.*.amazonaws.com issuer	AWS Cognito
JWT with *.auth0.com issuer	Auth0
JWT with *.okta.com issuer	Okta
JWT with login.microsoftonline.com issuer	Microsoft Entra ID
JWT with accounts.google.com issuer	Google
JWT with identitycenter.amazonaws.com issuer	AWS IAM IDC
JWT with tenant-configured issuer	Generic OIDC

Subject ID Mapping

Each provider maps to a canonical subject_id format used in mandates:

Provider	subject_id Format	Example
EUDI Wallet	eudi:<unique_id>	eudi:DE/1234567890abcdef
Auth0	oidc:auth0:<sub>	oidc:auth0:auth0|user123
Okta	oidc:okta:<uid>	oidc:okta:00u1234abcdef
Entra ID	oidc:entra:<oid>@<tid>	oidc:entra:abc-123@def-456
Google	oidc:google:<sub>	oidc:google:1234567890
AWS IAM IDC	oidc:aws-idc:<sub>	oidc:aws-idc:a1b2c3d4
Generic	oidc:<prefix>:<sub>	oidc:keycloak:user123
Cognito	cognito:<sub>	cognito:a1b2c3d4-e5f6

Tenant Role Assignments

Canonical subject_id values are also the keys used by tenant role assignments. After the authorizer resolves a caller through API key, Cognito, EUDI Wallet, Auth0, Okta, Entra ID, Google, AWS IAM Identity Center, or a tenant-configured OIDC provider, Mandaitor can enrich that subject with tenant-scoped roles and effective permissions from the tenant policy store.

Field	Purpose	Example
subject_id	Canonical identity key produced by the identity abstraction layer.	eudi:DE/1234567890abcdef
subject_type	Subject category used for governance and audit review.	NATURAL_PERSON, LEGAL_ENTITY, SERVICE, AGENT
roles	Tenant-scoped RBAC roles assigned to the subject.	tenant_auditor, tenant_viewer
permissions	Effective permissions derived from roles plus allowed explicit tenant grants.	tenant:read, events:read, evidence:read

Tenant administrators manage these assignments from the dashboard Access Management page or through GET /tenants/{tenantId}/roles and PUT / DELETE /tenants/{tenantId}/roles/{subjectId}. The policy model intentionally rejects platform_admin and platform:* grants because tenant policy may delegate only tenant-scoped authority. Assignment and revocation operations emit immutable TENANT_ROLE_ASSIGNED and TENANT_ROLE_REVOKED audit events so reviewers can reconstruct who granted access, which subject was affected, and which request caused the change.

Configuration

Each tenant configures their identity providers via the API or the dashboard:

curl -X PUT https://api.mandaitor.io/v1/tenants/{tenantId}/identity-providers \
  -H "Authorization: Bearer $TOKEN" \
  -d '{
    "enabled_providers": ["API_KEY", "COGNITO", "AUTH0"],
    "auth0": {
      "domain": "your-tenant.auth0.com",
      "audience": "https://api.your-app.com",
      "client_id": "your-client-id"
    }
  }'

See the individual provider guides for detailed setup instructions.

Cross-Provider Identity Binding

Mandaitor supports linking identities across providers. When a user verifies with the EUDI Wallet (high assurance), their canonical identity can be bound to their Auth0, Okta, or Entra ID accounts. This enables:

• Mandate portability: A mandate created with eIDAS identity can be used by the same person authenticating via their corporate Okta account.
• Progressive assurance: Start with OIDC authentication, upgrade to eIDAS HIGH assurance when needed.
• Audit continuity: All identity bindings are tracked in the audit trail.