Published · Updated
Session authentication for web, tokens for mobile
In my own browser applications I usually go with sessions and cookies. For an internal mobile app built with Ionic and Capacitor I chose access and refresh tokens instead, because an installed app talks to the backend outside any browser session.
- authentication
- sessions
- access tokens
- refresh tokens
- Laravel
- mobile applications
Browser apps: sessions and cookies
Laravel already handles server-side sessions, cookies and CSRF protection for browser requests. When the application and the browser client belong to the same system, that’s what I use.
Access and refresh tokens would mean extra code there for issuing, renewing and revoking them, and in those applications they wouldn’t cover anything the session didn’t already cover.
The mobile app: access and refresh tokens
The app was used at a printing company by warehouse staff and machine operators. The warehouse tagged paper rolls by type and brand, operators marked how much of a roll was left (start, middle or end), and the backend used that to track material use and stock.
The API had worked with sessions before. For the installed client the model was changed to access and refresh tokens: the backend issues credentials to the app instead of keeping a browser session for it. The token lifecycle became part of the mobile login flow, not something bolted onto the cookie-based web flow.
How I choose
For each client I look at where credentials can be stored, how access expires and how it can be revoked. In these projects that gave cookie-backed sessions for browsers and access and refresh tokens for the installed mobile app.