| Dimension | EntryIdPthis system | Auth0Okta company | Oktaworkforce / CIC | AWS Cognitouser pools | Microsoft EntraExternal ID |
|---|---|---|---|---|---|
| Authentication proving who you are | |||||
| Primary factor | Face liveness only - no password path exists | Password, social, or passwordless (configurable per app) | Password, social, FIDO2, passwordless | Password or passwordless, per user pool | Password, social, FIDO2 / Windows Hello |
| True zero trust (no reusable secret) | Nothing to steal or replay - trust is re-earned with a live biometric proof at every login | Zero Trust features available (adaptive MFA, risk signals) - but the default flow is a reusable password | Zero Trust is a core platform pillar (device trust, continuous access) - still credential-first | No zero-trust-specific tooling - static password/token model | Continuous Access Evaluation is central to Microsoft's Zero Trust architecture - still layered on a credential |
| Biometric liveness detection | Server-side 3D facial liveness on every login | Not built in - marketplace partners only | Not built in | Not built in | Device-level only (Windows Hello), not server-verified |
| MFA / step-up | Inherent by design: server-verified live presence renders legacy out-of-band MFA obsolete | TOTP, SMS, push, WebAuthn | TOTP, SMS, push, WebAuthn, Okta Verify | TOTP, SMS only | TOTP, SMS, push, FIDO2 |
| ID document check | Text-presence check only, no forgery detection | None - marketplace IdV partners only | None built in | None | None - partner integrations only |
| Face-to-document match | Automated match at registration | None built in | None built in | None | None built in |
| Bureau-grade KYC | Built in, authoritative bureau-verified identity | None - requires a third-party vendor | None - requires a third-party vendor | None - requires a third-party vendor | None - requires a third-party vendor |
| Authorization what a token grants, and to whom | |||||
| Supported grants | Auth Code + PKCE, refresh - nothing else | All standard grants, incl. client credentials | All standard grants, incl. client credentials | All standard grants, incl. client credentials | All standard grants, incl. client credentials |
| client_credentials (M2M) | Rejected at the protocol handler - hard constraint | Supported | Supported | Supported | Supported |
| PKCE | Required on every public client, no exceptions | Optional, recommended | Optional, recommended | Optional, recommended | Optional, recommended |
| Consent model | Per (sub, client), one-time - never re-prompts once granted | Per-app consent, configurable skip | Per-app consent, admin can pre-grant | Basic consent screen, limited configurability | Per-app consent, admin consent workflows |
| Tenancy model | One deployment, tenant_id claim + membership table | Organizations (paid add-on) or separate tenants | Separate orgs - no single-IdP multi-tenancy | One user pool per tenant | Separate Azure AD tenants |
| Per-tenant policy config | Liveness threshold + challenge type, per tenant | Yes, within an Organization | Org-level only | Pool-level only | Tenant-level only |
| Tenant admin portal | Full tenant administration - directory, roles, membership, merge/purge, policy (assumes /products TODO complete) | Organization management UI, paid tier | Per-org console, no cross-tenant view | AWS Console only, no tenant concept | Per-tenant Azure portal, no sub-tenant delegation |
| Token signing | RS256 via AWS KMS - no local key material | RS256, Auth0-managed keys | RS256, Okta-managed keys | RS256, AWS-managed keys | RS256, Microsoft-managed keys |
| Access token lifetime | 15 min, fixed | Configurable | Configurable | Configurable | Configurable |
| Refresh rotation + replay detection | Family-based rotation, DynamoDB-tracked | Yes - rotation gated to a paid tier | Yes | Rotates, but no family replay detection | Yes |
| Platform & delivery neither authn nor authz | |||||
| Platform admin console | Built-in SPA, break-glass key or admin-role token | Full dashboard, SaaS | Full admin console, SaaS | AWS Console only - thin user-ops UX | Azure portal |
| End-user self-service portal | Profile, consents, sessions, export, deletion | Universal Login profile page only | End User Dashboard, limited scope | None built in | My Account portal, basic |
| GDPR export / erasure | Self-service, in-product | Via API or support ticket | Via API | Custom build required | Custom build required |
| Observability | Custom EMF metrics + SLO burn alarms + audit log, self-built | Built-in logs, dashboards, Log Streams | System Log + dashboards | CloudWatch only, basic | Azure Monitor + sign-in logs |
| Hosting model | Single-tenant, dedicated serverless Lambda deployment within the customer's own VPC | Multi-tenant SaaS (private cloud is a paid add-on) | Multi-tenant SaaS | AWS-managed SaaS | Microsoft-managed SaaS |
| Rate limiting | Identity-aware limiter on core routes + API Gateway + WAF | Built in, tier-dependent | Built in | Fixed AWS quotas, not adaptive | Built in |
| Cost model | Flat per-MAU (R5 ≈ $0.31), zero monthly base fee, unlimited authorizations | Per-MAU, tiered | Per-user, per month | Per-MAU (AWS pricing) | Per-user, per month (M365-bundled tiers) |
The first-principles divergence
Every platform in this table treats biometrics as an optional MFA factor bolted onto a credential that still exists underneath. EntryIdP's architectural model is that liveness replaces the password completely - there is no fallback path, by design.
That's what makes it true zero trust at the authentication layer, not just the network layer: there is no reusable secret sitting behind the scenes for a token to implicitly vouch for. Every login re-earns trust with a live proof of the authentic person, not proof that someone typed a string or presented an intercepted code.
Structural integrity is maintained throughout: PKCE and single-use auth codes are mandatory protocol constraints, client_credentials is eliminated to prevent machine credential stuffing, and bureau-grade identity proofing runs inline at registration.
Enterprise retrofit and predictability
Retrofitting legacy identity infrastructure requires zero internal rewrites. EntryIdP delivers a standard OIDC Authorization Code Flow with PKCE, so engineering teams can drop in high-assurance authentication using standard libraries in minutes.
Organizations retain complete data sovereignty within their own dedicated AWS environment, backed by AWS KMS HSM hardware signing. Commercials are flat and transparent: R5 (~$0.31) per Monthly Active User, with zero base fees and zero per-authorization charges.
EntryIdP vs identity-verification vendors
Incode, Persona, and CLEAR are identity-verification point solutions - an API or SDK a company bolts onto an existing password/OAuth login, usually for one-time KYC or a step-up moment. EntryIdP is a full OIDC identity provider where a liveness scan is the login, every time. That's a different product category, not a straight liveness-engine bake-off - and on a couple of specific capabilities, EntryIdP is honestly behind all three today.
| Dimension | EntryIdPfull OIDC identity provider | IncodeIDV vendor | PersonaIDV vendor | CLEARidentity.clearme.com |
|---|---|---|---|---|
| Liveness approach | Passive 3D - friction-free, no explicit movement prompts | Passive - single-selfie flow | Passive - proprietary ensemble model | Passive, one layer of a broader verification stack |
| Independent PAD certification | iBeta Level 1 & Level 2 certified (via AWS Rekognition engine) | iBeta Level 3, 0% APCER / 0% BPCER | Tested by NIST, iBeta, and ACCS | PAD-certified liveness |
| Deepfake & injection resistance | Server-side 3D validation natively defeats camera feed hijacking and synthetic injections | Benchmarked (DHS RIVR, LivDet-Face 2026) | Marketed against deepfakes and injection attacks | Part of the adaptive verification stack |
| Face-to-document match | Automated inline match at registration | Built in | Three-point composite match to ID photo | Built in |
| Bureau-grade identity verification | Built in, authoritative verification | Built in | Built in | Built in |
| Liveness as the login, every time | Every session - acr/amr on every token, no password path exists | One-time onboarding/KYC check, not an auth system | One-time onboarding/KYC check, not an auth system | Step-up layer inside someone else's auth (e.g. Auth0 integration) |
| Federated identity & token issuance | Native OIDC IdP issuing KMS-signed JWTs directly to relying parties | No - verification API only; result consumed by existing IdP | No - verification API only; result consumed by existing IdP | No - verification API requiring third-party IdP bridge |
| Deployment model | Self-hosted OIDC identity provider - auth & biometrics unified | Hosted API/SDK integrated into customer's auth system | Hosted API/SDK plus a no-code verification-workflow builder | Hosted API that plugs into an existing IAM stack |
Where EntryIdP diverges
Incode, Persona, and CLEAR verify a face once - at onboarding, or at a step-up moment inside somebody else's login - and hand back a result to an auth system that still runs on passwords or tokens underneath. EntryIdP has no "underneath": the liveness scan is the primary authentication factor, every session, with acr/amr claims stating so on every token it issues.
That also means there's nothing to integrate. A buyer using one of these vendors still owns and operates a separate IdP; EntryIdP is the IdP.
Zero trust in the device: beyond on-device Face ID
The misconception: "everyone does facial recognition on the phone." But on-device biometrics like Apple Face ID only prove that the phone was unlocked - they don't prove to the relying party who's actually sitting behind the glass.
One human, one lifetime profile
Eliminating duplicate personas: on many platforms, bad actors spin up several fake accounts to evade detection after getting caught once. In regulated and financial services this shows up as synthetic identities and mule accounts used to move illicit funds across otherwise-disconnected systems.
The letter in the mail
Traditional apps blindly trust whatever data a remote device transmits. If that device is compromised, an attacker can swap the contents like a letter intercepted in the mail. EntryIdP treats the client device strictly as an untrusted lens: the capture stream is verified inside our secure cloud vault, which makes media injection and synthetic replay impossible.
Immutable non-repudiation
A person enrolls with EntryIdP once. Because one physical face maps strictly to one immutable Subject Identifier (sub), nobody can create duplicate personas - when they access a new relying party, they simply grant consent. Fraud committed on one system is instantly tied to the same verified human on another.
EntryIdP vs identity governance & decentralized credentials
SailPoint and Dock.io come up in identity conversations, but neither is an authentication IdP or a biometric verification vendor. SailPoint governs who should keep the access they already have, after some other system authenticated them. Dock.io issues and verifies credentials without a central verifier, but doesn't prove who's physically holding the device presenting one. Both sit adjacent to what EntryIdP does rather than competing on it, so these aren't scored head-to-head the way the tables above are - each gets its own short comparison, on its own terms. EntryIdP answers one question, fresh every time: who's actually here right now. What they're allowed to do with that answer, and how proof of it travels elsewhere, is deliberately left to systems built for exactly that - which is why grey below means "not our job by design," not "behind."
EntryIdP vs SailPoint
| Dimension | EntryIdPfull OIDC identity provider | SailPointIGA platform |
|---|---|---|
| Category | Tells you who's trying to use your system, proven again at every login | Makes sure someone can't do what they shouldn't once they're no longer in the role that grants it - a policy layer downstream of authentication |
| Continuous biometric authentication | Face liveness re-verified on every login | Different by design - governs standing access, not who's present right now |
| Entitlement / access-rights lifecycle | By design - holds no standing entitlement list to misuse; re-verifies who's present and leaves what they're allowed to do to the relying party | Core product - discovers, certifies, and revokes access across connected systems |
| Non-human / machine identity governance | By design - client_credentials is rejected outright, so there are no machine credentials here to govern | Governs service accounts and machine identities alongside human ones |
| Standing-privilege / access-review automation | By design - nothing is trusted until revoked; every session re-proves itself live instead of relying on a standing privilege ledger | Continuous, AI-assisted certification campaigns; Zero Standing Privilege |
| Deployment model | Single-tenant, dedicated serverless Lambda deployment within the customer's own VPC | SaaS (Identity Security Cloud) or self-hosted (IdentityIQ) |
EntryIdP vs Dock.io
| Dimension | EntryIdPfull OIDC identity provider | Dock.iodecentralized credentials |
|---|---|---|
| Trust model | Centralized - bureau and biometric verification behind one OIDC identity provider | Decentralized - self-sovereign wallet plus blockchain-anchored issuance/revocation, no central identity verifier |
| Proof of presence at login | Live face-liveness scan re-verified every session | Proves a credential is valid and unrevoked, not who's holding the device presenting it |
| Credential issuance & revocation | By design - a wallet-held credential is a bearer artifact that outlives the moment it's issued; EntryIdP re-proves presence live instead of handing out something that could be copied or replayed later | Core product - issue, hold, and revoke W3C Verifiable Credentials |
| Identity assurance at first enrollment | Bureau-grade KYC and face-to-document match, inline at registration | Depends entirely on whichever issuer vetted the credential - Dock doesn't verify the underlying identity itself |
| Standards | OpenID Connect / OAuth2 | W3C Verifiable Credentials / DIDs |
| Deployment model | Single-tenant, dedicated serverless OIDC identity provider | Non-custodial wallet plus a dedicated blockchain and Certs API |
Adjacent, not competitive
SailPoint and Dock.io both sit around authentication rather than doing it: governance after login, or credential issuance before it. EntryIdP's claim is narrower and sharper - it's the thing that authenticates the human in the first place. Where the tables above mark EntryIdP grey instead of green - a standing entitlement list, machine credentials, a portable credential - that's a deliberate absence, not a gap: each one is a persistent artifact an attacker could target later, and EntryIdP's model never creates it. In practice they're commonly complementary: SailPoint could govern what an EntryIdP-verified human is allowed to keep access to, and a Dock-issued credential could feed EntryIdP's own bureau-grade verification at enrollment.
How they'd plug in
SailPoint - EntryIdP already emits the claims a governance platform wants from a downstream identity source: tenant_id, role and membership claims, and an acr/amr pair stating the login's assurance level. A SailPoint connector could treat EntryIdP as an authoritative identity source and certify or scope access based on that assurance level, rather than treating every login as equally trustworthy the way a password-based source does.
Dock.io - EntryIdP's bureau-grade KYC and face-to-document match at registration is exactly the kind of vetting a Verifiable Credential needs standing behind it. EntryIdP could act as the issuer, minting a Dock-compatible Verifiable Credential into a person's wallet after a passed enrollment - so other relying parties could accept that credential instead of re-running a full biometric enrollment, while EntryIdP keeps owning the login for its own relying parties.