No vendor lock-in

We’re opposed to vendor lock-in, on both ethical and commercial grounds.

Why we oppose vendor lock-in

From an ethical standpoint we believe it’s wrong to tie developers to a particular platform. Vendor lock-in stifles innovation, which ultimately has a negative impact on the whole tech community.

From a commercial perspective, lock-in is actually counterproductive. Experienced architects and developers will not adopt a new platform that locks them in, the risk:reward ratio just doesn’t add up. Support can also be challenging, as vendors must support clients who frankly would be better served by a different solution, but are unable to migrate.

How we enable data portability

We take a number of steps to enable data portability as detailed below:

Passkey export

Export your complete passkey data including keys via our REST API or Node JS client library.

Passkeys are bound to your domain

To prevent phishing attacks, passkeys are bound to a specific domain. We register passkeys to your domain, not ours. e.g. yourdomain.com, not yourdomain.passlock.dev. If you decide to move away from Passlock, your passkeys will continue to work.

Note

The underlying WebAuthn specification does now support Related Origin Requests i.e. the ability to use a passkey on a different domain to the one on which it was registered.

However support for this feature is not universal and relies on the goodwill of the domain owner. If your passkeys are bound to acme.vendor.com, vendor.com would need to add the relevant entries to https://acme.vendor.com/.well-known/webauthn

Social logins

Note: Social login is on the roadmap

External identifiers

The Passlock Principal will also include the raw, external id:

{
  userId: "passlockUserId",
  google: {
    // you have access to the raw external ID
    userId: "googleUserId"
  }
}

If you decide to drop Passlock and instead implement Google login directly, you’ll still be able to map your existing user base via their Google identifiers. The same is true for Apple and any other providers we subsequently implement.