AIARCO ID vs VEREID Auth

We ship two OpenID Connect providers under one roof. They share the same Apache-2.0 OIDC core (aiarco-id-oidc) but target different customers and price points. This page is the deliberately-honest comparison so you pick the right one on day one.

TL;DR

• AIARCO ID — free, forever, drop-in Google-Identity-Platform replacement for ASC customers and the world. Lives at asc.aiarco.com/auth.
• VEREID Auth — paid, B2B, drop-in Auth0 replacement. Lives at auth.vereid.com. Adds custom domains, advanced MFA, hooks, SAML, enterprise SSO — and the killer vereid_verification custom claim that ships the user's identity-verification tier in your id_token.

If your app does not care about identity verification and you do not need enterprise features, pick AIARCO ID. If your app cares about who the signed-in user actually is — or you need any paid Auth0 feature — pick VEREID Auth.

Feature matrix

Shared code, separate operations

Both providers consume the same Apache-2.0 aiarco-id-oidc library. That means:

• Standards behaviour is identical bit-for-bit. A client written against AIARCO ID works against VEREID Auth and vice versa (modulo scopes).
• Bug fixes flow to both at the same time.
• Security audits and OIDC Conformance Suite runs cover both.

But the operational surfaces are completely separate:

• Different issuer URLs: https://asc.aiarco.com/auth vs https://auth.vereid.com.
• Different AWS accounts (AIARCO ID is in asc-prod; VEREID Auth is in vereid-prod).
• Different developer consoles (asc.aiarco.com/auth/console vs developer.vereid.com).
• Different SLAs (AIARCO ID has best-effort; VEREID Auth carries the paid SLA).

There is no shared user data. A user signing up at AIARCO ID does not automatically have a VEREID account.

When to pick AIARCO ID

• You are an ASC customer adding "sign in" to your app and you want zero auth bill.
• You are a hobbyist or OSS maintainer building a side project under 50K MAU.
• You do not need a custom domain on the login page.
• You do not need MFA beyond TOTP.
• You will never need SAML.

When to pick VEREID Auth

• You are migrating off Auth0 (paid feature parity).
• You need WebAuthn / passkeys.
• You need a custom domain on the login page.
• You need SAML federation for enterprise customers.
• You want the vereid_verification claim in your id_token.
• You need Hooks/Actions for custom business logic.
• You need audit-log export to your SIEM.
• You are above 1,000 MAU and you have revenue to back it.

When to use both

You can run AIARCO ID for free-tier signups and VEREID Auth for paid customers, with a per-tier OIDC client. The shared OIDC core means your SPA's auth code stays identical — only issuer and client_id change per tier.

A common pattern is to start free customers on AIARCO ID and upgrade them to VEREID Auth on their first paid conversion. Plumbing: store the user's sub in both providers using the same external id, and silently re-link the session on conversion.

Why two providers instead of one tier of features?

Because VEREID is GDPR-scope-sensitive (it touches biometric data via the linked Identity product). AIARCO ID deliberately stays out of that scope so it can offer a generous free tier without dragging every signup into a stricter compliance regime.

Keeping them separate also keeps the marketing positioning honest. "Free auth, like Google" and "paid auth with verified identity, like Auth0+Persona" are different value propositions; one product collapses both and inevitably under-serves one of the two audiences.

Migration between them

If you start on AIARCO ID and later need VEREID Auth's features, run both providers side-by-side for a billing cycle:

1. Add VEREID Auth as a secondary OIDC connection in your SPA.
2. New users go to VEREID Auth. Existing users keep using AIARCO ID.
3. Email existing users a one-time link to "upgrade" — under the hood we exchange their AIARCO ID id_token for a VEREID Auth account creation token via POST /v1/oidc/link.
4. Once everyone is migrated, drop AIARCO ID from your config.

There is no auto-migration — it would require pushing PII between two providers, which would require a separate consent flow per user. The opt-in linker above is the privacy-preserving alternative.