Skip to content

Authentication

This page explains how Campus WoL verifies user identity, protects stored passwords, manages sessions, and defends against brute-force attacks.

How Login Works

When you enter your username and password on the login page, the system checks your credentials against the stored password hash. If they match, the server issues a JWT (JSON Web Token) that your browser stores and sends with every subsequent request. This token proves your identity without requiring you to re-enter your password on every page.

The login flow is straightforward:

  1. You submit your username and password
  2. The server verifies the password against the stored Argon2id hash
  3. If valid, the server returns a signed JWT containing your user ID, username, and role
  4. Your browser includes this token in all API requests until it expires

Password Security

Passwords are never stored in plain text. Campus WoL uses Argon2id hashing, a modern algorithm that is intentionally slow to make brute-force attacks impractical. Even if an attacker obtained the database, they could not reverse the hashes back into passwords in any reasonable timeframe.

What is Argon2id?

Argon2id is a password hashing algorithm designed to be expensive to compute. Unlike fast hashes like SHA-256, Argon2id deliberately uses large amounts of memory and CPU time to produce each hash. This means an attacker who steals the password database cannot simply try billions of guesses per second -- each guess takes significant resources, making brute-force attacks impractical even with powerful hardware.

JWT Sessions

After a successful login, your session is managed by a JWT signed with the HS256 algorithm. The token contains your identity and role information, and the server verifies this signature on every request.

Sessions expire after 120 minutes by default. After expiry, you are redirected to the login page. The expiry duration is configurable by the system administrator through environment variables.

What is a JWT?

A JWT (JSON Web Token) is a compact, tamper-proof token that the server issues after you log in. It contains your identity information (who you are and what role you have) and is signed with a secret key. The server can verify the signature on every request without needing to look up a session in a database. If anyone modifies the token, the signature check fails and the request is rejected.

Rate Limiting

To protect against brute-force login attempts, the login endpoint uses a token bucket rate limiter. You can make up to 10 login attempts within any 5-minute sliding window. If you exceed this limit, additional attempts are temporarily rejected until a slot opens up.

Not a lockout

This is a sliding-window rate limiter, not an account lockout. Your account is never locked. As time passes, slots become available again and you can retry. There is no fixed penalty period -- requests resume as soon as capacity is available. Simply wait a few seconds and try again.

Rate limiting applies per client and is not tied to any specific user account. This prevents an attacker from locking out a legitimate user by flooding requests with their username.

Logging

All authentication attempts -- both successful and failed -- are recorded in the audit log. Each entry includes the timestamp, the username attempted, whether the attempt succeeded, and the client IP address. Administrators can review login activity in the Security Center.

Next Steps