Skip to main content

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

ProviderProtocolUse CaseStatus
EUDI WalletOpenID4VPeIDAS 2.0 European Digital IdentityAvailable
Auth0OAuth 2.0 / OIDCCustomer-facing apps (B2C/B2B SaaS)Available
OktaOAuth 2.0 / OIDCWorkforce identity (enterprises)Available
Microsoft Entra IDOAuth 2.0 / OIDCEnterprise identity (Microsoft ecosystem)Available
Google Cloud IdentityOAuth 2.0 / OIDCGoogle Workspace / consumer accountsAvailable
AWS IAM Identity CenterOAuth 2.0 / OIDCAWS SSO workforce identityAvailable
Generic OIDCOIDCKeycloak, PingIdentity, ForgeRock, etc.Available
AWS CognitoOAuth 2.0 / OIDCPlatform admin & tenant authenticationBuilt-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 FormatDetected Provider
Bearer tnt_xxx:mk_live_xxxAPI Key
Bearer eudi_session:xxxEUDI Wallet
JWT with cognito-idp.*.amazonaws.com issuerAWS Cognito
JWT with *.auth0.com issuerAuth0
JWT with *.okta.com issuerOkta
JWT with login.microsoftonline.com issuerMicrosoft Entra ID
JWT with accounts.google.com issuerGoogle
JWT with identitycenter.amazonaws.com issuerAWS IAM IDC
JWT with tenant-configured issuerGeneric OIDC

Subject ID Mapping

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

Providersubject_id FormatExample
EUDI Walleteudi:<unique_id>eudi:DE/1234567890abcdef
Auth0oidc:auth0:<sub>oidc:auth0:auth0|user123
Oktaoidc:okta:<uid>oidc:okta:00u1234abcdef
Entra IDoidc:entra:<oid>@<tid>oidc:entra:abc-123@def-456
Googleoidc:google:<sub>oidc:google:1234567890
AWS IAM IDCoidc:aws-idc:<sub>oidc:aws-idc:a1b2c3d4
Genericoidc:<prefix>:<sub>oidc:keycloak:user123
Cognitocognito:<sub>cognito:a1b2c3d4-e5f6

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.