Laravel ondersteunt nu native Passkeys

Wachtwoorden zijn al jaren stuk. Gebruikers vergeten ze, hergebruiken ze, en phishing pikt ze op nog voordat ze jouw server zien. Passkeys lossen dat op privésleutels blijven op het device, jij slaat alleen een public key op maar in Laravel betekende dat tot voor kort: een third-party package kiezen, hopen dat het onderhouden bleef, en je eigen glue schrijven rond Fortify of Breeze.

Sinds 12 mei 2026 is dat verhaal voorbij. Laravel heeft laravel/passkeys als first-party package uitgebracht, met directe integratie in Fortify en de starter kits.

Wat er nu in de doos zit

Drie stukken die op elkaar aansluiten:

• laravel/passkeys (Composer) — migraties, routes voor login en credential management, WebAuthn actions en events, en escape hatches als je custom autorisatie of responses wilt.
• @laravel/passkeys (npm) — handelt de browser-ceremonies af. Kleine core API met first-class helpers voor React, Vue en Svelte. SSR-safe hooks, dus de client-only APIs vechten niet met je framework.
• Fortify-integratie — Features::passkeys() plus een passkeys-sectie in config/fortify.php. Dezelfde endpoints en contracts (PasskeyUser, PasskeyAuthenticatable) zonder dat je de glue zelf hoeft te bouwen. Belangrijk detail: de Composer-package vereist illuminate/contracts: ^11.0|^12.0|^13.0. Je hoeft dus niet eerst naar Laravel 13 te upgraden om dit te kunnen gebruiken.

Hoe het er in code uitziet

Server-side komt het neer op een interface en een trait op je User-model:

use Laravel\Passkeys\Contracts\PasskeyUser;
use Laravel\Passkeys\PasskeyAuthenticatable;
 
class User extends Authenticatable implements PasskeyUser
{
    use PasskeyAuthenticatable;
}

Client-side is het twee method calls:

import { Passkeys } from '@laravel/passkeys'
 
// Een nieuwe passkey registreren voor een ingelogde gebruiker
await Passkeys.register({ name: 'MacBook van Norman' })
 
// Inloggen met een bestaande passkey
await Passkeys.verify()

In config/fortify.php activeer je het met Features::passkeys(). Vanaf dat punt heeft je app endpoints voor /passkeys/login, /passkeys/confirm/options en credential management. Fortify hangt er ook een dedicated rate limiter aan (fortify.limiters.passkeys), dus brute-force bescherming hoef je niet zelf in te regelen.

Drie dingen die je in productie raakt

1. APP_URL moet matchen met je browser-domein. WebAuthn gebruikt het als relying party identifier. Mismatch geeft cryptische errors en een gebroken flow. Test dit eerst lokaal en op acceptatie voordat je iets live zet.

2. HTTPS is verplicht. WebAuthn werkt alleen in een secure context. Valet, Herd of localhost zijn fine, maar http://192.168.x.x niet. Wij gebruiken Herd voor lokaal werk en dat is plug-and-play.

3. Laat de password.confirm middleware staan. Default beleid van de package is dat gebruikers hun wachtwoord (of een bestaande passkey) opnieuw moeten bevestigen voordat ze passkeys toevoegen of intrekken. Voelt als overhead, maar het is precies dezelfde bescherming die je op andere account-acties zou willen.

Wanneer is dit verstandig?

Voor nieuwe projecten: gewoon doen. Geen reden om in 2026 nog een wachtwoord-only app te bouwen.

Voor bestaande Stacks: een halve dag werk. Package installeren, contract implementeren, config-flag aan, frontend ceremonie aansluiten. Voor klanten met B2B-portalen of admin dashboards is dit een directe veiligheids- en UX-winst.

Wanneer niet: als je auth-flow zwaar custom is — bijvoorbeeld multi-tenant met aparte guards per subdomein, of als je SSO-provider de primaire login is — dan is de standaard integratie misschien te restrictief. In dat geval pak je de losse laravel/passkeys en bouw je de glue zelf. Dat blijft een paar uur werk in plaats van een week.

De conclusie

Passwordless auth is in Laravel nu net zo "boring to wire up" als sessie-auth. Voor de meeste apps die wij bouwen (SaaS-platformen, klantportalen, dashboards) is dit het soort feature waar je je gebruikers gewoon mee verrast. Sneller inloggen, geen wachtwoord-vergeten flows meer, en aanzienlijk minder phishing-risico voor accounts die er echt toe doen.

Heb je een Laravel project draaien waarin passkeys zinvol zouden zijn? Wij hebben de integratie inmiddels in meerdere productie-omgevingen draaien, laten we kijken wat het voor jouw gebruikers oplevert.