Skip to main content

Competitive Landscape

Authorization (OPA/Cedar):

  • We implement OpenID AuthZEN; native delegation graphs; built‑in explainability; CAEP/OTEL; p95 < 20 ms with caching

Authentication (Auth0/Okta):

  • Zero‑token ARIA Shield model; CAEP across services; self‑host option; integrated PDP for consistent authZ at the edge

Automation (Zapier/Make/n8n):

  • PDP‑authorized node execution with DPoP proof and CAEP audit; enterprise observability; on‑prem connectivity via Azure Relay

PDP competitors (AuthZ engines)​

Aserto (AuthZEN‑aligned PDP)​

  • What they say/do: Co‑proposers/co‑chairs of OpenID AuthZEN WG; native implementation positioning; public interop demos with multiple vendors. Source: Aserto AuthZEN overview.
  • Strengths:
    • Clear alignment with OpenID AuthZEN and PEP↔PDP model; credible standards advocacy
    • Developer‑friendly API and cloud‑managed offering; strong story for app‑level externalized authZ
  • Risks/constraints vs our Fabric:
    • Focused on PDP, not a full identity fabric (no ARIA Shield/session termination pattern, no Studios, no automation/inventory plane)
    • Operational surface limited to authorization; broader observability/CAEP coverage varies by integration
  • Where we win:
    • End‑to‑end, PDP‑guarded platform (Studios, ARIA Shield, Automation/Inventory) with zero‑token SPAs and CAEP/analytics by default
    • Runtime module activation and plugin model across UI, not only service‑side decisions

Cerbos (open‑source PDP + Cerbos Hub)​

  • What they say/do: Externalized, policy‑based, runtime authorization; open‑source PDP with enterprise Hub. Source: Cerbos.
  • Strengths:
    • Proven open‑source footprint; fast to embed; familiar ABAC/RBAC policy model; good developer tooling
    • Self‑host + managed options; success stories and partner ecosystem
  • Risks/constraints vs our Fabric:
    • Emphasis on PDP, not AuthZEN interop positioning across the board; no ARIA Shield/session termination or UI runtime model
    • Analytics, CAEP‑style events, and hybrid connectivity depend on customer assembly
  • Where we win:
    • Standards‑first (AuthZEN) across the fabric with built‑in CAEP/observability and hybrid connectivity patterns
    • Unified Studios + ARIA Shield + Data plane with policy gates on every call

Permit.io (AuthZ as a Service)​

  • What they say/do: Managed authorization service, policy & permissions management, developer SDKs. Source: Permit.io.
  • Strengths:
    • Rapid developer onboarding and UI for roles/permissions; hosted management plane
    • Bridges RBAC→ABAC use cases for app teams
  • Risks/constraints vs our Fabric:
    • Vendor‑managed control plane introduces lock‑in concerns for some enterprises
    • Not a fabric: lacks ARIA Shield, Studios, automation/inventory, and end‑to‑end observability out of the box
  • Where we win:
    • Composable, self‑hostable or SaaS fabric that standardizes AuthN/AuthZ/Automation with evidence (events/metrics/traces)

Axiomatics (enterprise ABAC; AuthZEN narrative)​

  • What they say/do: Long‑standing ABAC vendor; public narrative embracing AuthZEN era. Source: Axiomatics AuthZEN era.
  • Strengths:
    • Mature ABAC and fine‑grained policy history in large regulated enterprises
    • Clear thought leadership on centralized authorization
  • Risks/constraints vs our Fabric:
    • Historically XACML‑centric estates can be complex to operate and modernize for cloud‑native
    • Not a full identity fabric; lacks our ARIA Shield pattern, Studios, real‑time UI runtime and plugin model
  • Where we win:
    • Modern, standards‑driven AuthZEN across UI and service calls, with zero‑token SPAs and policy‑guarded automation

IdP competitor (AuthN with AuthZEN awareness)​

Curity (standards‑focused IdP; AuthZEN learning resources)​

  • What they say/do: High‑assurance OIDC/OAuth provider; publishes resources on AuthZEN concepts. Source: Curity AuthZEN learning.
  • Strengths:
    • Strong standards posture (OIDC/OAuth; often FAPI‑aligned) and security credibility
    • Enterprise‑grade IdP feature set; good developer docs
  • Risks/constraints vs our Fabric:
    • IdP‑first scope; customer must assemble PDP, ARIA Shield, CAEP, automation/inventory to reach “fabric” outcome
    • No unified Studios or runtime UI activation
  • Where we win:
    • Identity Fabric that unifies IdP+ARIA Shield+PDP+Automation/Inventory with built‑in eventing/analytics and UI runtime

Curity Token Handler (SPA security)​

  • What they say/do: Backend for Frontend authentication in the browser; issues secure HTTP‑Only, SameSite=strict cookies; routes API requests via an API gateway; uses an OAuth agent to issue cookies and an OAuth proxy on the gateway to translate them to tokens; offers plug‑and‑play compatibility with Azure API Management, Google Apigee, AWS, Kong and NGINX; positioned as a ready‑to‑deploy, low‑code solution. Source: Curity Token Handler
  • Strengths:
    • Plug‑and‑play with popular API gateways; follows OAuth best practices for browser apps (separates web vs API concerns via agent/proxy)
    • Reduces SPA auth complexity; mitigates token exfiltration/XSS via HTTP‑only cookies
    • Can be deployed without a firewall‑protected backend per their positioning
  • Constraints vs our Fabric/ARIA Shield (based on the product page’s scope):
    • Cookie→token translation happens at the API gateway; the page does not describe per‑endpoint, business‑context PDP mapping
    • The page does not highlight structured business audit streams or detailed authorization metrics
  • Where we win:
    • Application‑aware ARIA Shield behind Traefik with centralized PDP per‑route mapping (resource/action/id), SSE pre‑checks, per‑service token brokering, and enterprise observability (Kafka AUTHZ_DECISION, Prometheus). See: services/bff/explanation/bff_gateway.md, services/bff/explanation/bff_gateway_technical.md

Okta (Workforce/Customer Identity Cloud)​

  • What they say/do: Cloud‑native IdP with SSO, Adaptive MFA, Lifecycle, API Access Management; very large integration network. Sources: Frontegg guide, TechRepublic.
  • Strengths:
    • Mature SaaS IdP with extensive app integrations and adaptive authentication
    • Strong admin UX and ecosystem; fast time‑to‑value for SaaS SSO/MFA
  • Risks/constraints vs our Fabric:
    • No standardized OpenID AuthZEN decision API; app‑level authorization often baked into apps or via proprietary policy layers
    • Limited zero‑token SPA story (browser tokens) without ARIA Shield; CAEP/Shared‑Signals‑style eventing not first‑class across services
  • Where we win:
    • Standards‑first PDP (AuthZEN) enforced at ARIA Shield on every call, zero‑token SPAs, and event‑native analytics; composable with any IdP

Ping Identity (PingFederate/PingAuthorize)​

  • What they say/do: Enterprise IdP with on‑prem/cloud flexibility; PingAuthorize provides fine‑grained policy (PDP); AI via PingIntelligence for anomaly detection. Sources: Ping Identity (Wikipedia), TechRepublic, Ping blog: Entra external auth methods.
  • Strengths:
    • Strong in hybrid and regulated environments; explicit PDP (PingAuthorize) and broad protocol support
    • AI‑assisted threat detection (PingIntelligence)
  • Risks/constraints vs our Fabric:
    • PDP is product‑specific; no explicit OpenID AuthZEN decision API standard surfaced end‑to‑end
    • Not a full fabric with ARIA Shield session termination and runtime UI/plugin model
  • Where we win:
    • AuthZEN decision API across the stack, ARIA Shield‑enforced policy at every hop, CAEP‑style events, and Studios for rapid, policy‑guarded delivery

Microsoft Entra ID (formerly Azure AD)​

  • What they say/do: IdP with SSO, MFA, Conditional Access, PIM; deep Microsoft 365 integration. Sources: PeerSpot comparison, SelectHub.
  • Strengths:
    • Ubiquitous enterprise footprint; Conditional Access and Identity Protection provide risk‑adaptive authN
    • Tight integration with Microsoft ecosystem, good admin and compliance tooling
  • Risks/constraints vs our Fabric:
    • Conditional Access is IdP‑tier policy; no standardized PDP for application/service decisions (AuthZEN) out of the box
    • Requires customer assembly for CAEP‑style events across non‑Microsoft services and for ARIA Shield zero‑token SPA pattern
  • Where we win:
    • Vendor‑agnostic fabric with standardized PDP/AuthZEN, ARIA Shield session termination, CAEP‑style events, and automation/inventory guarded by policy

Automation competitors (no‑code/low‑code workflows)​

Zapier (SaaS app automations)​

  • What they say/do: Popular no‑code automation between SaaS apps with very broad integration catalog and simple linear “Zaps”. Source: massivegrid comparison.
  • Strengths:
    • Extremely easy to start; very large app marketplace and templates
    • Great for non‑technical teams to automate across SaaS tools quickly
  • Risks/constraints vs our Fabric:
    • Cloud‑only execution; secrets and data processed by vendor; limited policy/approvals context
    • Task‑metered pricing can spike at scale; limited deep on‑prem reach
  • Where we win:
    • PDP‑gated nodes with DPoP and CAEP audit, hybrid connectivity (Azure Relay), and zero‑token SPA control surface
    • First‑class observability (OTEL/Prometheus/Loki/Jaeger) and governance hooks

Make (formerly Integromat; visual automation)​

  • What they say/do: Visual drag‑and‑drop builder with advanced branching and transformations, wide app catalog. Source: massivegrid comparison.
  • Strengths:
    • Powerful visual scenarios with richer logic than basic zaps
    • Good coverage of SaaS integrations
  • Risks/constraints vs our Fabric:
    • Primarily vendor‑hosted; enterprise policy/approvals and audit depth vary by app
    • On‑prem and private connectivity require additional components
  • Where we win:
    • Standardized AuthZEN enforcement per node, end‑to‑end events/metrics, and on‑prem connectors as a first‑class runtime

n8n (open‑source, self‑hostable)​

  • What they say/do: OSS automation with self‑hosting and high customizability; also offers a hosted cloud. Sources: n8n blog, agixtech overview.
  • Strengths:
    • Self‑hosting for data control; custom nodes; developer‑friendly
    • Flexible for complex, non‑linear workflows
  • Risks/constraints vs our Fabric:
    • No native AuthZEN PDP gate, DPoP, or CAEP out of the box; security posture depends on assembly
    • Requires teams to curate observability, approvals, and governance patterns
  • Where we win:
    • Opinionated enterprise guardrails (policy‑gated nodes, CAEP, OTEL) and unified ARIA Shield/Studios surface for safe execution at scale

Identity Fabric vs traditional IGA (SailPoint, Saviynt)​

  • Analyst view: Identity Fabrics integrate IGA, Access Management, PAM, and more into a cohesive, standards‑driven, API‑first layer that spans cloud/on‑prem, supports all identity types, and emphasizes orchestration and adaptability. Source: KuppingerCole Identity Fabrics.

  • What traditional IGA excels at (SailPoint, Saviynt):

    • Lifecycle governance, certifications, SoD, and access reviews at enterprise scale
    • Mature connectors and compliance reporting for auditors
    • Saviynt’s cloud delivery modernizes deployment for IGA use cases
    • Sources: SailPoint overview, Saviynt overview

  • Where traditional IGA struggles vs an Identity Fabric:

    • Assembly & complexity: silos and heavy customization to stitch governance with runtime policy enforcement and modern app patterns. Sources: Common Clarity
    • Real‑time and runtime: slower feedback loops; limited real‑time CAEP‑style eventing and PDP decisions at the application edge
    • Hybrid execution: deeper on‑prem connectivity and low‑latency runtime policy often require additional platforms
    • Cloud posture: even with “cloud IGA,” broader fabric needs (ARIA Shield, PDP/AuthZEN, observability, automation) are outside core IGA scope

  • Our Identity Fabric differentiation:

    • Standards‑first PDP/AuthZEN at ARIA Shield on every call, with zero‑token SPAs and Shared‑Signals/CAEP‑style events
    • Built‑in Automation/Inventory guarded by policy, hybrid connectivity via Azure Relay patterns, and first‑class observability (OTEL/Prom/Graf/Loki/Jaeger)
    • Composable with any IdP/IGA: treat SailPoint/Saviynt as governance sources of truth while the fabric enforces runtime policy and provides evidence (events/metrics/traces)

Notes

  • We should expect continued consolidation and convergence on OpenID AuthZEN semantics and discovery. Competitors in PDP will strengthen interop stories rapidly; our advantage is a provable end‑to‑end fabric with ARIA Shield‑mediated zero‑token SPAs, Studios, and CAEP/observability baked in.
  • Keep this honest: for app‑only teams that “just need decisions,” a specialized PDP (Aserto/Cerbos/Permit.io) can be the fastest path. Our differentiation matters when buyers want one control plane for AuthN+AuthZ+Automation+Inventory with runtime UI, hybrid connectivity, and measurable evidence.