Applications 6 min

How Authentication Works in a Web Application

Short answer

Authentication in a web application is the process of verifying a user's identity before granting access. The application checks credentials (password, token, or third-party confirmation) and, once verified, issues a session token or JWT that the browser sends with each subsequent request. Authentication answers 'who are you?'; authorisation answers 'what are you allowed to do?'.

Authentication is how a web application verifies who you are. Understanding the basics helps you make better decisions about login flows, security, and access control in your own application.

Authentication vs Authorisation

These two terms are often used interchangeably, but they are different things. Authentication verifies identity: the application checks that you are who you claim to be. Authorisation determines what you can do once you are logged in. A user might authenticate successfully but then be blocked from certain pages or actions because their role does not have permission. Mixing up these concepts is a common source of security bugs. See user management and access control in web applications for how authentication connects to role management.

How Classic Password Login Works

When you submit a username and password, the application retrieves the stored record for that username, hashes the submitted password using the same algorithm used when the password was created, and compares the result to the stored hash. If they match, authentication succeeds and the server issues a session token or JWT that your browser stores. From that point on, your browser sends that token with every request, and the server uses it to identify you without asking you to log in again. Passwords are never stored as plain text; storing a one-way hash means a database breach does not automatically expose every user’s password.

OAuth and Social Login

OAuth is the protocol behind “Sign in with Google” or “Sign in with Microsoft” buttons. Instead of your application managing passwords, it delegates authentication to a trusted identity provider. The user authenticates with Google or Microsoft, and those services send your application a token confirming identity. Your application never sees the user’s password. This reduces your security responsibilities and lowers friction for users who already have accounts with those providers. For internal business tools, signing in with a company Microsoft account is often the most practical choice.

Two-Factor Authentication

Two-factor authentication (2FA) adds a second verification step after password entry, typically a one-time code from an authenticator app or sent via SMS. Even if a password is stolen, an attacker cannot log in without also controlling the second factor. For applications handling sensitive data, financial information, or admin functions, 2FA is strongly recommended. Most authentication libraries and third-party identity providers support it out of the box, so there is little reason not to include it from the start.

JWT Tokens: The Basics

A JWT (JSON Web Token) is a signed token the server issues after successful login. It contains encoded claims: user ID, roles, expiry time, and sometimes other metadata. The server signs it with a secret key; the client includes it in every API request. The server can verify the token’s authenticity without querying a database on every request, which makes JWTs efficient at scale. Keep JWT expiry times short (15 to 60 minutes) and use a refresh token mechanism to re-issue them without forcing re-login.

Our tip: Use an established authentication library or service (such as Supabase Auth, Auth0, or Clerk) rather than building login logic from scratch. Authentication has many edge cases and security pitfalls; the time saved by using a proven solution is always worth the dependency.

Frequently asked questions

What is the difference between authentication and authorisation?

Authentication verifies identity: it answers the question 'are you who you say you are?'. Authorisation determines permissions: it answers 'what are you allowed to do?'. In practice, authentication happens first (the user logs in), and authorisation happens on every request thereafter (the system checks whether the authenticated user has permission to perform the requested action). You can be authenticated without being authorised, for example when you log in successfully but try to access a page you do not have permission to view.

Why are passwords stored as hashes and not as plain text?

If a database is breached and passwords are stored as plain text, every user's password is immediately exposed. A hash is a one-way transformation: the original password cannot be recovered from the hash. When a user logs in, the application hashes the submitted password and compares it to the stored hash. Modern hashing algorithms like bcrypt or Argon2 add a random 'salt' to prevent pre-computed lookup attacks. This means even if an attacker gets the hashed passwords, cracking them requires significant computational effort per password.

What is a JWT and when do you use it?

A JWT (JSON Web Token) is a compact, signed token that contains a payload of claims (such as user ID, role, and expiry time). The server signs the token with a secret key; the client stores it and sends it with each API request. The server can verify the token's signature without querying a database, which makes JWTs efficient for stateless APIs and microservices. The tradeoff is that JWTs cannot be invalidated before they expire unless you maintain a revocation list, so use short expiry times and rotate them regularly.

Is OAuth the same as login with Google?

OAuth is the protocol that powers social login buttons. When you click 'Sign in with Google', your application redirects you to Google's login page. After you authenticate with Google, Google sends your application a token confirming your identity. Your application never handles your Google password. OAuth separates authentication from the application itself and delegates it to a trusted identity provider. OpenID Connect (OIDC) is a layer on top of OAuth that standardises how identity information is returned.

Want a dashboard or automation built for you?

Stuurboard BI builds custom Power BI dashboards and workflow automations. Pragmatic, fast, and without the fuss.