With the speed at which Generative AI is being used to build applications, knowing how to code isn't the complete way anymore; understanding what to code is. What is needed? Why is it needed? and more. I’ve decided to take some level of these concepts and explain them to the best of my abilities. Starting with backend development. First, let's understand authentication and authorization concepts.
Authentication is the process of confirming a user’s identity. Basically, it answers “Who is your user?”
Authorization is the process of confirming what a user can do. Basically, it answers “What can your user do?”
In this article, I’ll write about different authentication and authorization methods, what instances they’re used in, and how they work.
But first, we can’t talk about auths without mentioning passwords. Passwords are the most basic authentication method. But it is important to note, NEVER store passwords in plain text. It's the worst mistake any backend developer would make. The idea is to hash the passwords and verify the hash. There are many ways to hash a passwords, but here are 2 to avoid.
- MD5
- SHA-256
Why avoid them?
These general-purpose hash functions are designed to be fast, and an attacker with a modern GPU can compute millions of SHA-256 per second, making attacks computationally cheap, so when selecting hashing algorithms for passwords, they have to be deliberately expensive or slow. The 2 widely used are Bcrypt and Argon2. Both are designed to be slow and computationally expensive, making it harder for attackers to decipher them through brute-force attacks.
Bcrypt was designed in 1999; it is based on the Blowfish cipher and uses a salt to protect against rainbow table attacks. It also incorporates a cost factor that quantifies the hash's computational cost. The cost doubles with each increment, i.e., cost 10 is twice as expensive or hard as cost 9 was.
Argon2 was introduced in 2015 as the winner of the Password Hashing Competition. The edge it has over bcrypt is that it has resistance to side-channel attacks. You can read more on it later.
We will consider the following authentication methods:
- JWT Authentication
- Session-Based Authentication
- OpenID Connect Authentication
- MFA (Multi-Factor Authentication)
- SSO (Single Sign-On)
- Passkeys / WebAuthn (FIDO2)
- API keys
And the following authorization methods:
- OAuth 2.0
- RBAC(Role-Based Access Control)
- ABAC(Attribute-Based Access Control)
Starting with authentication,
JWT Authentication
Json Web Token(JWT) is a compact, URL-safe token that encodes a set of claims (key-value pairs) and is cryptographically signed. A unique feature is that JWTs enable stateless authentication; the signature is verifiable without a database lookup. The server can validate the token with just the secret key.
A JWT has 3 Base64URL-encoded parts separated by dots: Header, Payload, and Signature.
a. Header contains the algorithm and the type e.g
{ "alg": "HS256", "typ": "JWT" }
b. Payload contains the encoded claims, e.g
{
"sub": "user_id_123",
"email": "mike@synoloop.com",
"role": "admin",
"iat": 1716000000, // issued at (Unix timestamp)
"exp": 1716003600 // expires at (1 hour later)
}
c. The signature is the encrypted base64url header and payload with the secret.
In real-world authentication systems, JWTs are most commonly used in two forms: Access tokens and refresh tokens.
Access tokens are short-lived, between 5 and 15 minutes. Refresh tokens, on the other hand, are long-lived from days to even weeks and are used to obtain new access tokens without reauthenticating (depending on the developer).
But what happens if a token is stolen or a user logs out of the system? Since JWTs are stateless and valid until they expire, we need a way to invalidate them before their natural expiration. This is where token blacklisting comes in.
This is solved by maintaining a server-side denylist. Once any of the above events happen, the JWTID is added to the blacklist.
So on logout or password change or compromise, it's best to revoke or blacklist all existing refresh tokens. This logs out the user on all sessions. On each request, the server looks up the session ID, retrieves the session data, and authenticates the user.
Session-Based Authentication
Session-based authentication stores the auth state on the server, so when a user logs in, it creates a session record and stores it. What makes Sessions different from JWTs is that Sessions are easier to revoke immediately, but require server-side storage. JWTs are stateless but harder to invalidate before expiry.
In sessions, it's best to always regenerate the session ID after login to prevent session fixation attacks.
OpenID Connect (OIDC) Authentication
OIDC is an identity layer built on top of OAuth 2.0(Will be discussed in authorization). OIDC answers who this user is. It adds a standardized ID token(a JWT) containing identity claims.
Think of this as when you use any web application that has a “continue with Google”; this sends your name, email, phone (and other details if requested) from Google to the web application authorized, answering who you are.
It gives the addition of what an OAuth 2.0 gives.
- ID Token: a JWT containing user identity (sub, email, name, picture, etc.)
- UserInfo Endpoint: returns additional claims about the authenticated user
- Discovery Document: /.well-known/openid-configuration for automatic configuration
- Standard Claims: sub (subject/user ID), email, email_verified, name, picture
MFA( Multi-Factor Authentication)
Multi-factor authentication requires users to have two or more verification factors present: something they know (password), something they have (phone/hardware key), and something they are (biometric).
Multi-factor authentication includes methods like TOTP and Backup Codes.
TOTP(Time-Based One-Time Passwords), generates a 6-digit code that changes every 30 seconds based on a shared secret and the current time. It works with apps like Google Authenticator, Microsoft Authenticator, and such.
Backup Codes: These are a list of 8 to 10 single-use random codes that can be used to retrieve the account or authenticate.
SSO(Single Sign-On)
Single Sign-On allows users to authenticate once and gain access to multiple systems. This is mostly used in enterprise environments or applications; the 2 main protocols are SAML 2.0 (XML-based, older) and OIDC-based SSO (modern, JSON/JWT-based).
SAML is the standard in enterprise environments (corporate identity providers like Okta and Azure). It uses XML assertions to tell the identity. The identity provider (IdP) authenticates the user and sends a signed XML assertion to the service provider (SP).
- Service Provider (SP) is your application
- Identity Provider (IdP) is Okta, Azure, Google Workspace, etc.
- An assertion is a signed XML document asserting identity and attributes.
Passkeys / WebAuthn (FIDO2)
Passkeys are an advanced form of authentication: passwordless, phishing-resistant, and cryptographically strong. Based on the WebAuthn standard (W3C) and FIDO2 protocol, they use public-key cryptography with biometrics or device PINs.
Passkeys have become popular since their release in 2018. They work in 2 major steps:
- Registration: The browser or the device generates a public/private key pair. Private key stays on the device. The public key is sent to your server.
-
Authentication: Server sends a challenge. The device signs the challenge with the private key. The server verifies with the stored public key.
No Password is ever transmitted or stored, and attackers can’t do anything with just the public key.
API keys
I chose to keep API keys under authentication, but underneath, they do both authentication and authorization; I’ll explain.
API keys are Opaque tokens issued for programmatic access to services, scripts or public-facing APIs.They should be scoped, rotatable, and auditable.
API keys act like a username and password pair, but simplified. They identify the calling application or developer. For example, A weather API requires an API key to ensure only registered apps can access data.
While some APIs use keys with scoped permissions (e.g., read-only or read and write).
Example: A developer can generate API keys in a payment app and may allow one key to process transactions but another only to view reports.
Some design principles of API keys include:
- Including a prefix for easy identification (e.g., sk_live_, sk_test_, syno_)
- Generate with cryptographically secure randomness (at least 128 bits)
- Store only the hash in your database, treat keys like passwords
- Support scopes/permissions per key
- Log all usage with timestamps for auditing
- Support rotation: allow multiple active keys per user, then invalidate old ones
Now, let's consider the authorization concepts:
OAuth 2.0
This is an authorization framework that allows a third-party application to obtain limited access to a service on a user's behalf without exposing credentials. You can think of this as “connect to GitHub” or authorizing Google Drive access via a “connect to Google.” It's about what you can access, not about who you are.
RBAC(Role-Based Access Control)
RBAC Controls access by assigning permissions to roles, and roles to users. This is most common in authorization models for web applications. User has a role, and the role has permissions. For example, in an e-commerce application. There are key roles like Admin, Vendor, and User. Each of these roles has different permissions. Admin can read all users and vendors, edit or verify, or ban a vendor. The vendor can upload products, the user can read and purchase products.
ABAC(Attribute-Based Access Control)
ABAC is another authorization method. It evaluates attributes of the user, the resource, the action, and the environment to make an authorization decision. For example, consider that a manager can edit a document only if they are in the same department as the document's owner, during business hours. We can see that many conditions affect the action that can be carried out by the manager.
When to Use ABAC vs RBAC
- Use RBAC when access rules map cleanly to roles and don't depend on resource data
- Use ABAC when you need fine-grained rules like row-level security, ownership checks, or time-based restrictions
- Many systems use both: RBAC as a coarse gate, ABAC for fine-grained resource access
This is the conclusion of my article. We’ve considered various authentication and authorization concepts.
Please show your appreciation by giving this a like, leaving a comment with something encouraging, or sharing something you just learned, or something I may have gotten wrong. Thanks for reading.
Top comments (0)