Können wir mit Sanctum anfangen und später wechseln?

Ja, und das ist die richtige Reihenfolge. Passport hinzuzufügen, wenn tatsächlich eine Fremdintegration auftaucht, ist eine begrenzte Arbeit, und beide können während des Übergangs nebeneinander laufen. Mit Passport anzufangen, falls man es braucht, heißt, für ein Problem zu zahlen, das man vielleicht nie hat.

Ist Sanctum weniger sicher?

Nein. Es gibt undurchsichtige Tokens aus, gehasht in Ihrer Datenbank gespeichert, mit Fähigkeiten und Widerruf, und für einen eigenen Client ist das genau die richtige Form. OAuth2 ist nicht abstrakt sicherer - es löst Delegation, was ein anderes Problem als Authentifizierung ist.

Wie funktioniert der SPA-Modus?

Er verwendet gar keine Tokens. Eine eigene Single-Page-Anwendung auf derselben Top-Level-Domain authentifiziert sich mit dem gewöhnlichen Session-Cookie, mit intaktem CSRF-Schutz - es gibt also kein Token im Browser-Speicher, das gestohlen werden könnte. Das ist die sicherste verfügbare Option und die, die übersprungen wird.

Sanctum vs. Passport: die meisten wählen das Teure

Q: Wie lautet die Regel in einem Satz?

Gehört der Client Ihnen, nehmen Sie Sanctum; gehört er jemand anderem, Passport. Alles andere folgt daraus, denn OAuth2 existiert, damit ein Dritter im Namen eines Nutzers handeln kann, ohne dessen Passwort zu halten - ein Problem, das Sie mit Ihrer eigenen Anwendung nicht haben.

Passport implementiert OAuth2 - richtig für fremde Clients und ein teurer Fehler für Ihr eigenes Frontend. Die Entscheidung hängt an einer Frage: wem der Client gehört.

Veröffentlicht am 21. September 20263 Min. Lesezeit

Das ist die häufigste vermeidbare Entscheidung in einer Laravel-API, und sie geht oft genug falsch aus, um einen ganzen Artikel zu rechtfertigen.

Die Frage ist nicht, welches Paket besser ist. Sie lautet, wer das Token hält.

Wofür OAuth2 tatsächlich da ist

OAuth2 existiert, damit ein Dritter im Namen eines Nutzers handeln kann, ohne dass der Nutzer sein Passwort herausgibt. Das ist das Problem, das es löst: Delegation über eine Vertrauensgrenze hinweg. Der Zustimmungsdialog, der Authorization Code, die Client Credentials, die Scopes - all das existiert, um genau diesen Austausch sicher zu machen.

Ist der Client Ihre eigene React-Anwendung oder Ihre eigene Mobile-App, gibt es keine Vertrauensgrenze und keine Delegation. Der Nutzer authentifiziert sich direkt bei Ihnen. OAuth2 löst hier nichts und stellt Ihnen die Maschinerie trotzdem in Rechnung.

Was das kostet, wenn es falsch ist

Passport bringt einen OAuth2-Server in Ihre Anwendung: Client-Tabellen, Authorization Codes, Access- und Refresh-Tokens, Schlüsselerzeugung, Token-Introspektion und eine Upgrade-Oberfläche, die aktuell bleiben muss.

Ihr Team betreibt jetzt einen OAuth2-Server. Es wird Refresh-Token-Rotation debuggen, jemandem Client Credentials erklären und Schlüsselrotation im Deployment behandeln. Alles, damit Ihre eigene Mobile-App sich anmelden kann.

Es wird auch auf erkennbare Weise falsch gebaut: Password Grant, weil der Redirect-Flow für eine eigene App keinen Sinn ergibt, das Client Secret in dieser App ausgeliefert, wo es kein Geheimnis ist, und eine Token-Lebensdauer, die jemand auf ein Jahr gesetzt hat, damit die Beschwerden aufhören.

Sanctum, was die meisten APIs wollen

Undurchsichtige Tokens, gehasht gespeichert, mit Fähigkeiten und Widerruf je Token:

$token = $user->createToken('mobile', ['orders:read'])->plainTextToken;

Nichts aufzusetzen, nichts zu rotieren, und Widerruf ist das Löschen einer Zeile. Für eine Mobile-App, eine CLI oder einen Server-zu-Server-Schlüssel für einen Kunden ist das die richtige Form.

Was übersehen wird: Sanctum hat einen zweiten Modus, der noch besser ist.

Für eine eigene SPA gar kein Token

Wird Ihre Single-Page-Anwendung von derselben Top-Level-Domain wie die API ausgeliefert, authentifiziert Sanctum sie mit dem gewöhnlichen Session-Cookie:

GET  /sanctum/csrf-cookie      → setzt das CSRF-Cookie
POST /login                    → normaler Session-Login
GET  /api/orders               → cookie-authentifiziert, CSRF-geschützt

Kein Token in localStorage, also nichts, was ein Cross-Site-Scripting-Fehler stehlen könnte. HttpOnly, SameSite, CSRF-Schutz - der ganze Satz an Browser-Schutzmechanismen, den Token-im-Speicher-Authentifizierung aufgibt.

Teams überspringen das, weil "es eine API ist und Tokens braucht". Braucht sie nicht, und das ist die sicherste Anordnung für einen eigenen Browser-Client.

Wann Passport wirklich richtig ist

Anwendungen anderer Unternehmen binden sich an Sie an. Sie müssen für Ihre Nutzer handeln, Sie brauchen Zustimmungsdialoge und abgegrenzten Zugriff, und Sie müssen eine Integration widerrufen können, ohne etwas anderes anzufassen.

Sie sind der Identitätsanbieter. Andere Systeme authentifizieren gegen Sie.

Eine Standardanforderung. Ein Partner oder ein Beschaffungsprozess schreibt OAuth2 vor, und darüber wird nicht verhandelt.

Beachten Sie, was diese gemeinsam haben: Jemand außerhalb Ihrer Organisation hält die Berechtigung. Das ist der ganze Test.

Zwischen ihnen wechseln

Von Passport zu Sanctum, wo Passport irrtümlich gewählt wurde: beim Login Sanctum-Tokens ausgeben, während eines Übergangsfensters beide akzeptieren, dann keine Passport-Tokens mehr ausgeben und es entfernen. Begrenzt, meist eine Woche.

Von Sanctum zu Passport, wenn eine echte Fremdintegration auftaucht: Passport für die Fremdflüsse installieren und Sanctum für die eigenen Clients behalten. Sie koexistieren mit verschiedenen Guards. Auch deshalb kostet es nichts, mit Sanctum anzufangen - Sie stehen nicht in der Ecke, Sie zahlen nur nicht im Voraus.

Die Regel, noch einmal

Ihr Client, Ihr Token: Sanctum. Der Client eines anderen, der für Ihren Nutzer handelt: Passport.

Wenn Sie den Dritten nicht benennen können, brauchen Sie OAuth2 noch nicht - und die Versionsrichtlinie, die Sie für diese API schreiben, wird ihren Konsumenten weit wichtiger sein als das Paket, das das Token ausgestellt hat.