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 its 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 counter productive. 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 portability

You can export your passkeys

We allow you to export your users’ passkeys via the console and API. Data is exported in a standardised format, compatible with other platforms and libraries.

Passkeys are bound to your domain

To prevent phishing attacks, passkeys are bound to a specific domain - a passkey registered against site-one.com can’t be presented on site-two.com, therefore a passkey registered to acme.passlock.dev could only be used on passlock.dev. If we adopted this approach (as some vendors do), you’d be locked in to using us.

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

We preserve external identifiers

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

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

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