Authentication Flows
Last updated
Last updated
When a user logs in, they provide their username and password. The API then takes these inputs, checks them against the database, and ensures that the usernames and passwords match, with appropriate security measures like hashing and salting in place.
If the credentials match, the user gains access to the website and can perform various actions, such as an authenticated admin deleting a user’s account upon receiving a deletion request.
Unauthorized users attempting to make this request are denied access because they lack the necessary permissions.
To identify who is sending the request, the request can include the authenticated user’s user ID. This prevents unauthorized users from making such requests because they do not possess the same user ID.
In a system utilizing cookie-based user/session ID storage for authentication, Cross-Site Request Forgery (CSRF) and Cross-Site Scripting (XSS) attacks pose distinct threats.
CSRF attack
An attacker tricks a user into making an unintended request, often by luring them into clicking a malicious link or loading a compromised webpage.
If the user is authenticated, their session cookie gets automatically attached to the request, allowing the attacker to perform unauthorized actions on their behalf.
XSS attack
This attack involves injecting malicious scripts into a trusted website.
When another user visits this compromised site, the malicious script executes within their browser, potentially allowing the attacker to steal their session cookies, thus gaining unauthorized access to their account.
How to secure the session tokens?
However, to prevent malicious actors from impersonating an admin by inserting an authenticated user’s ID, session tokens are introduced.
A session is tied to the admin’s machine, and a separate database contains a session table linking users to session IDs.
When the admin logs in, the API securely generates a session ID and stores it in the database. The admin includes this session ID in their requests to the API for authentication. This adds an additional layer of security, as malicious actors would need to discover the admin’s session ID to impersonate them.
Privacy and security upgrades are essential in generating session IDs to make them random and statistically impossible to brute force by bad actors.
Storing these tokens can be done using cookie-based storage, which involves attaching a small piece of data, including the session ID, to the website. Alternatively, session IDs can be stored in local storage, a separate storage area within the browser.
JSON Web Tokens and Current De-centralized Authentication Methods
JSON Web Tokens are an open, industry-standard RFC 7519 method for representing claims securely between two parties. Unlike the access token, which the client may not fully understand, the ID token is a uniquely formatted string of characters known as a JSON Web Token (JWT) that the client can easily interpret.
These JWTs contain vital information, including your ID, login time, expiration, and security checks against tampering.
JSON Web Tokens (JWTs) consist of a header, payload, and signature. The header specifies the encryption algorithm and token type (JWT). The payload contains application data such as the user’s username.
The signature ensures data integrity by encrypting the header and payload with a secret key stored on the client. When users want to send an API request, they include the JWT, and the API uses asymmetric encryption to verify the data’s integrity using the token’s signature.
