What is Auth
When we talk about Auth, we usually tend to discuss auth packages but auth is just 2 things — Authentication and Authorization
Authentication — Who this user is, and are they actually who claiming to be (confirm the person’s credibility)
Authorization — check what the person is allowed to / access to (check whether the person can do this task or not)
What is Auth in layman’s language?
If you enter Airport to board an airplane, front gate security only allows you when you prove your identity
authentication
.You are only
authorized
to board an airplane when you have a valid air ticket, destination, and airplane details that match the airplane.
Where this Auth takes place
If you think auth takes place on the client side(frontend), WRONG. It would and should only happen on the server side (backend)
- If there is an edit/ delete button on this blog page,
who is me and whether I can access this button
should be validated in the server on request by the client
Why not happen in the client
They are only meant for requesting the server and have no right to take action on their own
If the client wants to know who the user is or whether this action can be made by the user, we don't check local storage or session, just make a request to the server and ask it
Why we don't check local client storage -
It does not sync over time
It's not validated for each action/ session
It’s prone to hacker/ external JS files (like browser extensions)
Authentication VS Authorization
Authentication | Authorization |
Check whether users are who they claim to be | Check what users can and can't access |
Validate the user's credentials | Check whether user's access is allowed through policies and rules |
Happen before authorization | Only happen after the user is authenticated |
Usually done with login process like username-password, social auth(github, google), and OTP | Usually done with token IDs |
Authentication flow
Authentications happen only when the user comes to the website in a new tab/ browser (session/ non-session auth)
On selecting logging-in/ sign-in, the client requests the server with necessary data (like the user’s username, password/ OTP …)
The server then validates the request and responds with a secure cookie for that session
Client stores that secure cookie in local storage in a way it’s not accessible by external JS files
On all further requests to the server, the client appends the secure cookie to validate the user’s actions
Authorization flow
Client requests for user action/ data (whether to show this page for this user)
The server receives the request and greps the secure cookie from it
The server checks what the user cookies for
It checks if this authentication user is authorized for this action
At last, the server responds whether auth or not
High-level explanation in 2 lines?
If a user accesses a webpage, the client requests the server whether the current user is authenticated or not. If authenticated, then render the page or else redirect to the login page and ask the user to log in first
Once the page is rendered upon successful authentication, whether the user can edit the page or delete a post is all authorized with a new request
Outro
In short, if you can’t prove your identity, you won’t be allowed inside the resource. If you prove your identity and are not authorized to the resource, then sorry my friend peace out — You are denied using the resource