Authentication Basics: Sessions, Tokens and OAuth Explained

Almost every web app needs to know who its users are. Logging in seems simple from the outside, but under the hood there are several common approaches, each with trade-offs. Junior developers often hear terms like sessions, JWT and OAuth without a clear picture of when to use each.

This guide explains the main authentication methods in plain language, with practical advice for small business web apps.

Authentication vs Authorisation

First, two terms that are often confused. Authentication answers "who are you?", usually by checking a password, a code or a social login. Authorisation answers "what are you allowed to do?", such as whether a user can view invoices or edit products.

Both matter, and many security problems come from apps that authenticate users correctly but forget to check authorisation on every request. A logged-in customer should never be able to view another customer's order just by changing an ID in the URL.

Session-Based Authentication

Sessions are the traditional approach used by many server-rendered apps, including those built with Laravel, Django and Rails. The flow is simple:

1. The user submits a username and password.
2. The server checks them and creates a session record.
3. The server sends a cookie containing a random session ID.
4. The browser sends that cookie with each request, and the server looks up the session.

Sessions are easy to revoke, because deleting the session on the server logs the user out immediately. They work well for traditional websites and admin dashboards. Secure cookie settings are essential: HttpOnly so JavaScript cannot read the cookie, Secure so it is only sent over HTTPS, and SameSite to reduce cross-site request risks.

Token-Based Authentication and JWT

Token-based authentication is common for APIs and mobile apps. After login, the server issues a token that the client sends with each request, often in an Authorization header. A popular format is the JSON Web Token, or JWT, which contains signed information about the user.

• JWTs can be verified without a database lookup, which helps with scaling across services
• They are convenient for mobile apps and separate frontend applications
• They are harder to revoke before they expire, so keep access tokens short-lived
• Refresh tokens are often used to get new access tokens without logging in again

Tip: do not store sensitive data inside a JWT. It is signed, not encrypted by default, so anyone holding the token can read its contents.

Where to store tokens in a browser is a frequent debate. Storing them in localStorage makes them reachable by malicious scripts if your site has an XSS flaw. Many teams prefer HttpOnly cookies even for token-based setups.

OAuth and Social Login

OAuth is a standard that lets users grant an app limited access to their account on another service. In practice, most developers meet it through "Log in with Google" or similar buttons, usually implemented with OpenID Connect on top of OAuth.

Social login can reduce friction for users and remove the need to store passwords yourself. However, it adds dependency on external providers and requires careful handling of redirects and tokens. Use well-maintained libraries rather than writing the flow from scratch, and always validate tokens according to the provider's documentation.

Security Essentials for Any Approach

Whatever method you choose, a few practices apply everywhere:

• Hash passwords with a modern algorithm designed for passwords, never store them in plain text
• Use HTTPS everywhere, without exception
• Add rate limiting and lockouts to slow down password guessing
• Offer two-factor authentication, at least for admin accounts
• Regenerate session IDs after login to prevent session fixation
• Log out users properly by invalidating sessions or tokens on the server

For API-specific protections, our guide on API security basics goes deeper into keys and rate limits.

Choosing the Right Approach

For a typical small business website or admin panel built with a server-side framework, sessions are usually the simplest and safest choice. For a mobile app or a separate frontend talking to an API, tokens make more sense. For consumer apps where sign-up friction matters, adding social login can help.

Many frameworks bundle well-tested authentication starter kits. Using them is not cutting corners. It is choosing proven code over home-made security, which is almost always the right call for small teams.

FAQ

Is JWT more secure than sessions?

Not inherently. Both can be secure or insecure depending on implementation. Sessions are often simpler to get right for traditional web apps.

Should I build my own login system?

Use your framework's built-in authentication or a trusted library. Writing it from scratch invites subtle security bugs.

Do I need two-factor authentication for a small app?

At minimum, enable it for admin and staff accounts. Offering it to customers is a good extra layer, especially for apps holding personal or payment data.

Authentication is a solved problem if you use proven tools and follow the basics. Pick the approach that fits your app's architecture, secure your cookies and tokens, and always check authorisation on every request.