Big picture of what Auth is

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 -

1. It does not sync over time
2. It's not validated for each action/ session
3. It’s prone to hacker/ external JS files (like browser extensions)

---

Authentication VS Authorization

---

Authentication flow

1. Authentications happen only when the user comes to the website in a new tab/ browser (session/ non-session auth)
2. On selecting logging-in/ sign-in, the client requests the server with necessary data (like the user’s username, password/ OTP …)
3. The server then validates the request and responds with a secure cookie for that session
4. Client stores that secure cookie in local storage in a way it’s not accessible by external JS files
5. On all further requests to the server, the client appends the secure cookie to validate the user’s actions

---

Authorization flow

1. Client requests for user action/ data (whether to show this page for this user)
2. The server receives the request and greps the secure cookie from it
3. The server checks what the user cookies for
4. It checks if this authentication user is authorized for this action
5. 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