Policy decides.
The substrate orchestrates.
An OIDC-native pause/resume engine that turns "authorization blocked" into a resumable, auditable, multi-step journey — without reconstructing a fragile synthetic login.
The PDP says "this user must complete X first." The Interaction Substrate handles the rest — collecting evidence, preserving PKCE integrity, and resuming the original authorize flow when every obligation is fulfilled.
Login flows shouldn't be hardcoded.
Most identity platforms treat orchestration as an afterthought — XML policies, code snippets in login pipelines, or event-driven hooks that can't pause and resume a login. When you need a partner to verify their email, enroll a passkey, and accept terms before their first session, these approaches break down.
Hardcoded login flows
Every new identity journey requires a code release. Progressive profiling? New code. Passkey enrollment? New code. Partner signup? Custom build from scratch. Engineering becomes the bottleneck for every identity change.
Broken OIDC integrity
Multi-step login customizations often reconstruct a "fake" authorize call at the end. PKCE code_challenge, state, nonce — lost or fabricated. The OIDC spec is violated by the very system supposed to implement it.
No rollback on failure
Partner signup fails after email verification but before org activation. Now you have an orphaned identity, a dangling claim, and a manual cleanup ticket. Most platforms have no concept of compensation for multi-step flows.
Orchestration disconnected from authorization
Login customizations and authorization decisions live in separate products with separate integrations. "This user needs to complete their profile" is a policy decision — but it has to be wired manually into the login flow.
The Interaction Substrate
A reusable, OIDC-native engine that sits between /authorize and session issuance. It pauses the login, runs obligation-driven steps, collects typed evidence, and resumes the original authorize context with full PKCE/state/nonce integrity.
Steps come from policy, not code
The PDP emits typed obligations — "require email verification," "require passkey enrollment," "require profile attributes." The substrate interprets them, routes to the right handler, and collects evidence. Change behavior by deploying a policy, not releasing code.
One substrate, every journey
The substrate has zero knowledge of partner signup, progressive profiling, or passkey enrollment. It knows obligations and evidence. The same engine handles today's flows and tomorrow's — step-up MFA, consent refresh, identity proofing, account linking — without new substrate code.
True authorize pause/resume
The original PKCE code_challenge, state, nonce, redirect_uri, and client_id are preserved across the entire multi-step journey. Resume uses them to continue the standard authorize flow. No reconstructed requests. No security shortcuts.
Prove the obligation was fulfilled
Each completed step produces typed evidence — what was fulfilled, who provided it, when, and the obligation-specific payload. Evidence is stored in the transaction, emitted to the governance pipeline, and available for audit.
Authorization-native orchestration
Most platforms keep authorization and orchestration in separate products with separate integrations. EmpowerNow connects them by design — the PDP decision drives the orchestration flow.
Built-in identity journeys
Three production flows ship today — all built on the same substrate. New journeys require a policy and a config change, not code.
B2B Partner Onboarding
Self-service signup, invite-based enrollment, and approval workflows — all on a single platform instance. Policy-driven org isolation. Compensation sagas for clean rollback if any step fails.
Progressive Profiling
The PDP evaluates profile completeness on every login. Missing attributes trigger a require_attributes obligation with a specific fields list. The substrate routes to a profiling workflow. Users complete their profile inline — no separate enrollment portal.
Passkey Enrollment
Two strategies: soft nudge (skippable on first login) and policy-driven mandatory enrollment. Both use the same substrate. The obligation carries a credential_type hint for the WebAuthn endpoint. Evidence records enrollment or skip.
Future journeys — same substrate: Step-up MFA, consent refresh, terms acceptance, identity proofing, account linking. Add a PDP policy, map the obligation type in config, and restart. No substrate code changes. No container rebuild.
B2B Partner Onboarding — minutes, not weeks
Self-service signup, invite-based enrollment, and approval workflows — all on a single platform instance. Policy-driven org isolation. Compensation sagas for clean rollback. Three-artifact governance at every step.
How partner signup works
If any step fails: Compensation sagas automatically roll back prior steps. No orphaned identities. No dangling claims. No manual cleanup tickets.
Policy-driven isolation
Scope modes (partner, hub, service) determine what each user can see. Cross-org access is denied by default at the PDP layer. All partner organizations share one platform instance — isolation is policy-driven, not infrastructure-driven.
Registration modes
Three modes, all config-driven: Open (self-service), Invite-only (hub sends invitation), Approval-required (hub operator reviews before activation). Switch modes by changing YAML — no code release.
SignupClaim → OrgEntity lifecycle
Claim verification and org activation are separate lifecycles. A claim can be pending while the identity is verified. Once approved and activated, the partner org is live with role assignment, program enrollment, and member management.
Built for partner ecosystems
Manufacturing & dealers
Onboard hundreds of dealers. Each sees only their own warranty claims, incentives, and parts catalog — enforced at the policy layer.
Supply chain & logistics
Carriers and 3PLs get exactly the data they need. Change access rules by deploying a policy. Hand auditors the governance feed.
Franchise & retail
Each franchise location gets an isolated org with self-service member management. Regional VPs see cross-franchise dashboards.
Healthcare ecosystems
Labs, imaging centers, payer orgs. HIPAA-ready isolation. Mandatory approval gates. Federation-first credentials for clinical staff.
Financial services
Brokers, agents, distribution partners. Every access grant produces a tamper-evident proof chain for regulators.
Reduction in partner provisioning time
Serves 1,000+ partner orgs
Audit prep with pre-built proof bundles
New partner types via YAML config
Add a new identity journey without code
Obligation types are an open vocabulary. The substrate routes them through config. Partners and customers extend the platform without source access.
Security built into every layer
The substrate was designed for regulated environments where replay attacks, token theft, and partial-state corruption are audit findings, not edge cases.
Replay protection
Every interaction token carries a unique JTI consumed on first use. Resume handles are marked redeemed after session issuance. Second attempt returns 409 — no replay possible.
Signed redirects
Resume URLs are HMAC-SHA256 signed with configurable expiry. Constant-time comparison prevents timing attacks. Tampered or expired URLs are rejected.
PKCE continuity
The original code_challenge, code_challenge_method, state, and nonce are stored in the Redis transaction — never exposed in tokens, never reconstructed. Resume restores the exact OIDC context.
Idempotent step completion
Same evidence for the same step returns success (safe retry). Different evidence for a completed step returns 409 Conflict. No partial state corruption on any error path.
Transaction state machine
active → completed (all obligations fulfilled) → redeemed (session issued). Terminal states cannot be reversed. Expired transactions are automatically evicted.
Three-artifact governance
Every lifecycle event — started, step_completed, completed, resumed, session_issued — emits a Kafka event, a tamper-evident ProofBundle, and a queryable AuditEvent. Compliance is built in.
How EmpowerNow compares
Identity orchestration is a crowded category. Here's where EmpowerNow is genuinely different — and where competitors have strengths.
| Capability | EmpowerNow | PingOne DaVinci | Okta | Auth0 | Azure AD B2C |
|---|---|---|---|---|---|
| Visual flow designer | ReactFlow canvas | Flow Studio | — | — | IEF (XML) |
| AI workflow generation | Natural language → canvas | — | — | — | — |
| Authorization-native obligations | PDP → substrate | Separate PingAuthorize | Static auth policies | — | Conditional Access (binary) |
| OIDC authorize pause/resume | PKCE-preserving | Flow-based tokens | — | — | — |
| B2B partner onboarding | Full lifecycle | Custom flow | Custom build | Organizations (basic) | External Identities |
| Progressive profiling | Policy-driven (included) | Template flow | — | Forms (paid add-on) | Custom IEF |
| Compensation sagas | First-class rollback | Error branches | — | — | — |
| Replay protection (JTI) | Per-token + per-handle | Standard | — | — | — |
| Three-artifact governance | Kafka + ProofBundle + AuditEvent | 10 recent events | System Log (90d) | Log streams | Azure Monitor |
| Self-service connector creation | YAML + UI + API spec import | Vendor-built only | — | — | — |
| Self-hosted / air-gapped | On your infrastructure | SaaS only | SaaS only | SaaS only | Azure only |
Technical deep-dive Under the hood: Interaction Substrate internals
InteractionTransaction (Redis)
The transaction is the central state object keyed by an opaque resume_handle. It stores the full OIDC context (client_id, redirect_uri, PKCE code_challenge/method, state, nonce, acr_values), the obligation list, completed steps, step evidence, subject_arn, org_id, and correlation_id. TTL-configurable (default 3 days). Status follows a strict state machine: active → completed → redeemed.
Interaction token (JWT)
RS256-signed JWT with: iss (key ID), aud (workflow consumer), sub (subject ARN), txn (resume handle), jti (unique, consumed on complete_step), flow_type, step (current obligation), nonce, optional required_fields and acr_target. Default TTL: 600 seconds.
Obligation type vocabulary
Built-in types with extensible open vocabulary:
require_attributes require_acr require_consent require_approval require_email_verification require_credential_enrollment require_terms_acceptance require_identity_proofing require_account_linking Consumer routing
Three consumer types: Internal (default — redirect to Orchestration Service workflow start), Webhook (external URL receives interaction_token + resume_handle; calls back complete endpoint with evidence), and IdP-hosted (Python endpoint for flows requiring direct IdP integration like WebAuthn). Consumer registry lives in settings.yaml.
Governance event pipeline
Six lifecycle events, each producing three artifacts (best-effort, non-blocking): interaction.started, interaction.step_completed, interaction.completed, interaction.resumed, interaction.session_issued, interaction.expired. All published to Kafka topic authz.partner.changed and persisted as ProofBundles. Correlation ID threads the entire journey.
B2B partner graph model
Partner data lives in Neo4j: OrgEntity, SignupClaim, OrgProgram, Invitation nodes with BELONGS_TO_ORG, CHILD_OF, program binding, and role edges. Graph edges are canonical; materialized properties are projections for query performance. PIP queries feed the PDP with derived context: subject_scope_mode, subject_scope_org_id, resource.scope_org_id.
B2B compensation sagas
The signup workflow registers compensating actions for each step. If email verification succeeds but org activation fails, the saga reverses: delete the identity, revoke the claim, emit governance events for the rollback. No partial state. No orphaned accounts.
B2B configuration knobs
All in YAML — registration mode (open / invite_only / approval_required), credential mode (federation_first / password_allowed), allowed org types, CAPTCHA provider, duplicate detection threshold, presentation mode (managed / themed / headless). Deploy changes without rebuilding.
What this means for your organization
New identity journeys go from engineering sprints to config changes. Deploy a policy, not a release.
Compensation sagas roll back partial state on failure. No dangling identities, no manual cleanup.
Every lifecycle event produces three artifacts. Trace any identity journey from start to session with a single correlation ID.
True OIDC authorize pause/resume with PKCE preservation. No security shortcuts. No synthetic authorize calls.
Explore the connected platform
AuthZEN Authorization →
The PDP that emits obligations driving orchestration flows.
Identity Governance →
Lifecycle management for partner and internal identities.
Zero-Trust OAuth Vault →
Tokens never leave the server — the credential security layer.
Connector & Tool Factory →
48 YAML connectors with self-service creation.
See orchestration in action
Watch us describe a partner signup flow in natural language, generate it on the visual canvas, run it live, and trace the governance trail end to end.