Authentication:(who you are)?
Check if this system/user is really who they claim to be? (Whenever you login to an App/web, whether with a password, Google login, or a token. that's authentication.
Authorization: (What you can do)?
Once you're authenticated, Authorization decides you can read your email, upload files, or access the admin dashboard.
Explanation:
Basic Auth:
The simplest form is Basic Authentication.
Login -----> base64 encoded ----> (Server decodes + Check for match)
Client sends username and password with every request.
These credentials are base64 encoded with an HTTP header.
Server decodes them and checks if they match.
This auth is easy to implement, but it is not secure if not wrapped with HTTPS.
Base64 is not encryption.
Anyone who intercepts it can decode it instantly.
use case example: internal tools, quick tests, or systems behind firewalls.
Bearer Tokens:
User --------> Client -------> Server
1 ----login-------------access----->
2 <--------access granted-----------
Instead of sending (username & password) every time, the client first authenticates once and receives a token.
From then on, every request carries a token in the authorization header.
Server Simple Check if the token is valid to access granted, if not access is denied.
Stateless token instead of a password.
Standard for APIs.
OAuth2:
Client -------sign in with Google---------> App -----------> API
OAuth2 is not a token, it's a protocol ( a framework that defines how applications can delegate authentication).
e.g,
If you login to an app using a Google account.
You click on Sign in with Google.
Google authenticates you, then issues a token to that App.
This way App never sees your Google password.
It just gets a secure confirmation from Google that you are you.
OAuth2 is a foundation for modern login with X, flows like Google, GitHub, Facebook, etc.
JWT (json web token):
JWT is not an authentication method.
It's a token format.
Think of JWT as the envelope that carries claims about the user. A JWT usually contains three parts:
"Header":
which contains the metadata.
"Payload":
with claims for user ID, email, expiration, roles,
"Signature":
Signature used to verify it hasn't been tampered with.
Token format carrying signed claims.
The key benefits are that they are self-contained and verifiable.
The Server doesn't need to store session data.
It just verifies the token Signature.
Access + Refresh Tokens:
short-lived + long-lived combo for security.
Modern systems rarely rely on one long-lived token.
Instead, they use a 2-token model.
Access: short-lived, 15min to 1hrs, used for actual API calls.
Refresh: long-lived days or months, used only to request a new access token.
e.g,
You login and get both tokens.
Then you use an Access token for API calls.
When it expires, your App silently uses the Refresh token to get a new Access token.
This keeps the system secure because stolen access tokens become useless quickly.
While Refresh tokens are typically stored more securely, often on the server side.
SSO (Single Sign-On):
One login, multiple service access.
One Google account has access to YouTube, Gmail, etc.
SSO uses identity protocols like SAML on older systems but still popular in enterprises.
OAuth2 and OpenID Connect in modern software and are used by most Apps today.
Top comments (0)