1. Vendor and Product Reality
OneLogin is a cloud identity and access management platform founded in 2009 and acquired by One Identity, a business unit of Quest Software, in 2021. It sits in the workforce IAM and single sign-on market, providing a hosted identity layer that brokers access between a workforce directory and the SaaS and internal applications those employees use. Its positioning has always been operational simplicity: a smaller, cleaner alternative to heavier legacy IAM suites, with fast time to value for organizations standardizing employee access on a cloud control plane.
The product surface is coherent and well built. The Trusted Experience Platform provides single sign-on across SAML and OIDC applications, a directory service with an Active Directory connector that synchronizes on-premises directories to the cloud, SmartFactor Authentication for risk-adaptive multi-factor challenges, and Smart Hooks, serverless extensibility points that let administrators inject custom logic into the login and provisioning pipeline. User provisioning and deprovisioning, SCIM lifecycle flows, a browser extension and vaulting for password-only applications, and a policy engine for context-based access round out the surface. Within the federated-credential paradigm, OneLogin is a capable and legitimate product, and the comparison here is not with its execution.
Market posture is the streamlined-workforce-SSO position. Where Okta, Microsoft Entra, Ping Identity, and OneLogin's own parent portfolio compete on breadth, governance depth, or ecosystem, OneLogin's differentiation has been the clean administrative experience and the lower operational footprint. That is a real advantage, and it is orthogonal to the architectural axis this article addresses.
2. The Architectural Difference
The structural property OneLogin's architecture does not exhibit is identity that does not depend on stored, signed key material. Federated SSO is, by construction, a credential-issuance machine. The identity provider authenticates the user once, then mints an assertion, a signed SAML response or an OIDC ID token, that downstream applications accept as proof of identity. The trust of that assertion rests on a signing key held by the identity provider and a public-key trust chain the relying party validates against. The session that follows is itself a stored artifact carried in the browser. Each of these is a portable object whose possession is, by design, sufficient to act as the identity it represents.
This is not a defect in OneLogin. It is the shape of federation. SAML and OIDC are standards whose security model assumes a signing authority and a verifiable signature over an issued token. The dominant remaining attack patterns against well-run SSO deployments are credential-shaped for exactly this reason: adversary-in-the-middle phishing that captures a post-authentication session cookie and replays it, stolen tokens lifted from a compromised endpoint, and compromise of signing-key material. The mitigations the category offers, short token lifetimes, session binding, continuous access evaluation, adaptive step-up, reduce the window and raise the cost, but they operate on an issued credential. The architecture has no shape in which there is no portable, signed artifact whose theft is equivalent to identity theft, and no shape in which proof of identity is possible without an available trust root at the moment of validation.
The specification underlying Keyless Identity names this same class of problem at the architectural level: conventional identity systems rely on persistent keypairs and signature-based validation, which expose deployments to key compromise, certificate revocation failure, metadata correlation, and centralized trust anchors that are impractical in decentralized, disconnected, or memory-constrained environments. The point is not that OneLogin does its job poorly. It is that the job, as the category defines it, is anchored to stored credentials and an external verification authority.
3. What the Keyless Identity Primitive Provides
Keyless Identity, disclosed in United States Patent Application 19/388,580, specifies a memory-native identity substrate in which a device or agent expresses identity as a trust slope rather than a stored credential. The trust slope is the cumulatively validated, append-only sequence of dynamic hashes, Dynamic Agent Hashes (DAH) or Dynamic Device Hashes (DDH), formed by successive verifiable identity mutations. Each step is computed from the immediately prior step and a source of non-exported unpredictability under an update rule of the form DAH_t = H(DAH_{t-1} || contribution_t || salt_t || tag), where the contribution is drawn either from a static hardware anchor combined with a volatile per-epoch salt, from a locally observed state vector transformed by a strong extractor, or from a hybrid of both. Because each step binds to the prior step and to unpredictability that never leaves the device, a party lacking the device's local state cannot feasibly synthesize a valid successor.
Three load-bearing properties follow directly from the disclosure. First, there is no portable, signed assertion to steal or replay: identity is validated by checking that a presented dynamic hash is an on-slope successor of a previously trusted state under policy-bounded continuity criteria, not by verifying a signature over an issued token. Second, validation is local and needs no authority at the moment of proof: a receiver stores a previously trusted step and evaluates the successor from locally retained lineage, which the specification shows working even in disconnected, high-latency, or intermittently connected deployments through bounded proofs, embedded checkpoints, and periodic anchors. Third, there is no long-lived signing key whose compromise is systemic: where an entanglement trace is authenticated at all, the specification uses either a message authentication code keyed from the contemporaneous device hash or an ephemeral per-epoch signing key that is destroyed on rotation, preserving the no-persistent-keypair property.
The specification enumerates the mechanisms that make this operational and auditable, and they are the substance of the disclosure rather than the assertion: two-stage message validation that places a dynamic hash in the transport header for fast stateless screening and embeds the same value inside the encrypted payload to bind semantics to transport; stateless symmetric encryption in which keys are derived transiently from the recipient's current dynamic identity so no session material persists; spoofing and replay resistance enforced by monotonic on-slope progression and non-reuse of accepted successors; append-only mutation lineage logs with cumulative chain hashes and periodic anchors for tamper-evident provenance; agent-to-substrate entanglement binding each identity transition to the device it executed on; quorum-based recovery that re-admits an agent after memory loss using attestations from previously trusted peers rather than a stored secret; entropy-anchor rotation with forward links that preserve verifiability across reseeding, including an optional biometric-assisted reseed through a privacy-preserving fuzzy extractor whose seed is never stored or exported; and predictive drift detection that forecasts the expected successor neighborhood and flags behavioral divergence before continuity breaks. A skilled implementer has, from the specification, the update rule, the validation procedure, the message format, the recovery and rotation paths, and the embodiment variations needed to build the approach.
4. Composition Pathway
The honest framing is that Keyless Identity does not replace OneLogin's product; it changes what sits under the assertion. OneLogin's differentiated layer, the clean administrative console, the SAML and OIDC federation library, SmartFactor risk policy, Smart Hooks extensibility, directory synchronization, and SCIM lifecycle, is exactly the layer customers pay for and is orthogonal to how the underlying identity is proven. That layer stays.
What changes is the primitive beneath it. A keyless connection type joins the existing connection registry alongside directory-backed and federated connections. An application that opts into it continues to receive a standards-compliant assertion; what differs is what the assertion attests. Instead of attesting that a bearer presented a password and second factor at time T, it attests that a continuity-validated keyless identity with a given trust slope was observed at time T. The OIDC and SAML contract with the relying application is unchanged, and existing connections keep working side by side. Trust slope becomes a first-class signal to SmartFactor: step-up policy can require a continuity-strength threshold rather than, or in addition to, a second factor, and a device whose slope broke recently is a distinguishable posture from one with a long, smooth history. Enterprise federations wrap cleanly, an upstream IdP attestation enters the trust slope as a high-weight observation, after which subsequent authentications are continuity-validated locally rather than re-federated. The composition is additive.
The result the customer gains is authentication that does not produce a stealable, signed post-authentication artifact, a continuity signal that lets risk policy price step-up against actual behavioral consistency, and a validation path that works in disconnected and edge conditions where a call to an external trust root is not available. Those are the specific architectural axes the specification provides, and they are the terms on which this comparison is scoped.
Disclosure Scope
The Keyless Identity mechanism described here, in which identity is a locally retained, append-only trust slope of dynamic hashes validated by continuity checks, with stateless symmetric messaging, agent-to-substrate entanglement, append-only lineage, quorum recovery, entropy-anchor rotation, and predictive drift detection, and requiring neither a certificate authority nor an external attestor nor a persistent keypair at the moment of proof, is disclosed in United States Patent Application 19/388,580. All statements in this article about what the invention does trace to that filing. References to OneLogin, One Identity, Quest Software, and to SAML, OIDC, and related standards describe publicly known products and specifications and are provided as external market and architectural context for comparison only; they are not claims of the filing. Where a competitor capability is characterized, it is characterized at the level of the federated-credential architecture the category shares, not as a defect specific to OneLogin's implementation.
