Sanctum and choosing how much auth you need

Airlock lived for about a week. Laravel 7 shipped it this month, a trademark scare followed, and it became Sanctum. Fast rename, same idea. And the idea is good, because it names a problem people solve badly.

The problem: your own SPA needs to talk to your own API. For years the reflex was OAuth2. Install Passport, stand up an authorization server, issue JWTs to a frontend on the same domain as the backend. All that machinery to authenticate first-party code against itself. OAuth is a delegation protocol, it lets a third party act for a user. When there is no third party, you are running a passport office for your own family.

Sanctum gives two smaller tools. For the SPA, plain session cookies plus CSRF. The browser already knows how to store a cookie, no token in localStorage waiting for the first XSS. For mobile apps and scripts, personal access tokens: a random string in the database with a list of abilities. Revocable, per device, boring.

My decision now. Same-domain SPA, session. Mobile app or CLI, token. A real third party integrating on behalf of your users, only then OAuth2, and you will know, because someone external will ask for a client id.

One habit worth keeping from the OAuth world: scope the tokens. A token that can do everything is a password with extra steps. Sanctum abilities are primitive next to OAuth scopes, but ['orders:read'] on a reporting integration still saves you the day that token leaks.

Auth has levels. Pick the lowest one that covers your threat model.

I installed Passport on a same-domain SPA in 2018. It is still there. Nobody wants to be the one who touches auth.