Security basics for Philippine SME apps covers unique logins, MFA, and session timeouts. It does not say where the session lives. For a Nuxt app talking to Laravel, that choice is a cookie or a bearer token.
Laravel Sanctum documents both. The SPA authentication flow is the cookie. API tokens are the other client.
Use the cookie when the browser is yours
A first-party Nuxt app on the same site — or on a domain you have configured as stateful — should use the cookie session. The cookie is httpOnly. The page’s JavaScript does not need to read it. CSRF protection is the tradeoff Sanctum’s SPA notes walk through, and it is the right tradeoff for an app you control.
How we build is one Laravel backend and a Nuxt client. That client should not be holding a long-lived bearer token in local storage because a tutorial did. A token the page can read is a token an injected script can read.
Use a token when the client is not the site
A phone app, a partner, a script. Issue a token, scope what it can call, and be able to revoke it without logging every browser out. API-first backends treat mobile as a client of the same rules. A token is how that client authenticates. It is not a reason to skip revocation, and it is not the staff session cookie reused in an app binary.
What we will not do
- One never-expiring token shared by the admin and the public site.
- CSRF turned off because “the frontend and the API are both ours.”
- A separate auth service before Sanctum is actually the wrong tool. For this shape of app, it usually is not.
Session timeout and MFA from the security-basics article still apply. They sit on top of this choice. They do not replace it.
Straight next step
If the admin and the public site share one long-lived token, tell us where it is stored. We will move the first-party browser onto a cookie session and leave tokens for clients that are not the site.
