The POC is built with a React frontend and an Express + TypeScript backend, implementing OAuth from scratch without using any OAuth-specific frameworks .

The deployment setup is fully production-style:
• Frontend on Vercel.
• Backend on AWS EC2.
• NGINX used for load balancing across my other services and handling SSL termination.
• A rate limiter implemented at the backend level to protect the EC2 instance from abuse, excessive requests, and potential denial-of-service scenarios. This ensures better stability, security, and controlled resource usage under real-world traffic patterns.

(If you’re interested in learning more about NGINX configuration , rate limiters or deploying services on EC2, I’ll cover those topics in future blogs depending on the engagement this series receives) .

Rather than swaying here and there , let’s focus on the topic currently on hand → so then lets go to system design we will follow for implementing authentication here -

We can use this pattern for any of the auth providers , but for sake of simplicity , we will follow google OAuth / OIDC services .

We will break the approach in three basic parts -

1. Password based Authentication .

2. OIDC/OAuth based Authentication .

3. Admin level authorization ( bonus ) + way to set password after logging in via google + Two Token Setup .

before going into each of the steps , lets look into the schema first -

enum Auth {
    GoogleLogin
    PasswordLogin
    Both
}

model User {
  id            String    @id @default(uuid())
  email         String    @unique        // required + unique
  passwordHash  String?                   // for email/password login
  googleId      String?   @unique         // for Google OAuth 
  name          String                    // required
  refreshToken  String?   @unique         // only one refresh token per user
  createdAt     DateTime  @default(now())
  updatedAt     DateTime  @updatedAt
  authType      Auth      @default(PasswordLogin)
}

apart from general user data , we are using passwordHash , googleId and authType for handling both authentication methods ,

• passwordHash used to store the hashed password in case of email / password login

• googleId used to store the id received from google in case of google login

• authType tells which type of auth is used , google , password or both

Password Based Authentication

In Password Based Authentication ,

Both Login and Registration ( account creation ) will take place in two steps -

we will take email and password from the user , check if the password and email are correct and if so then we give the required cookies ( namely access token and refresh token ) to the client browser and log in the user.

Let’s discuss how to implement Email Password Login -

Firstly , user will fill a form with email and password and then a POST request will be sent from the client side to the application server -

await axios.post(
        `${BACKEND_URI}/v1/auth/login`,
        {
          email: data.email,
          password: data.password,
        },
        {
          headers: {
            "Content-Type": "application/json",
          },
          withCredentials: true,
        }
      );

And now on the application server , we will deal with the data , check in the db if the user exists and then issue access and refresh token to the client browser based on the availability of user account .

        const {email , password} = req.body
        if(!(email && password)) throw new ApiError(411,"Either email or password is missing")

        const user = await db.user.findUnique({
            where : {
                email
            }
        });

        if(!user?.passwordHash) {
            throw new ApiError(411,"Either account not present or logged in through google")
        }

        const passwordCheck = await bcrypt.compare(password,user.passwordHash);

        if(!passwordCheck) throw new ApiError(406,"password is not correct");

        const accessToken = generateAccessToken(user.id);
        const refreshToken = generateRefreshToken(user.id);

        const loggedInUser = await db.user.update({
            where : {
                id : user.id
            },
            data:{
                refreshToken
            },
            select:{
                id:true,
                name:true,
                authType:true,
            }
        });



        return res
        .status(201)
        .cookie("accessToken",accessToken,accessTokenCookieOption)
        .cookie("refreshToken",refreshToken,refreshTokenCookieOption)
        .json({
            message:"user logged in",
            data: loggedInUser
        })

As we are already discussing about logging in the user lets also look into creating a user account . Similar to Login , a form will be filled in the client browser and data will be sent to the application server via a POST request .

await axios.post(
        `${BACKEND_URI}/v1/auth/register`,
        {
          name: data.name,
          email: data.email,
          password: data.password,
          type:"PasswordLogin"
        },
        {
          headers: {
            "Content-Type": "application/json",
          },
        }
      );

and on the application server side as well most of the things will remain the same . We will first check if the user exists in the db , if not we will hash the password and save the user data along with passwordHash in the db .

        const { name,email,password } = req.body ;
        if(!(name && email && password)){
           throw new ApiError(411,"either of name , email & password is missing")
        } 

        const existingUser = await db.user.findUnique({
            where:{
                email,
            }
        })

        if(existingUser) throw new ApiError(411,"User already exists")

        const hashedPassword = await bcrypt.hash(password,10);


        const createdUser = await db.user.create({
            data:{
               name,
               email,
               passwordHash:hashedPassword,
               authType:"PasswordLogin"
            }
        });

        return res.status(201).json({
            message:"createdSuccessfully",
            data:createdUser
        })

This is mainly how we deal with Password Based Authentication in general .

Now moving to the main part of the blog handling Authentication with OIDC/OAuth

OIDC/OAuth Authentication

Firstly get the credentials ( namely , client secret and client id ) from the auth provider , for this blog it will be google .

In the frontend have a sign in/sign up with google button , which will basically redirect to authorization server , along with redirect uri and client id as url param .

<Button
       variant="outline"
       className="w-full text-white cursor-pointer"
       disabled={isSubmitting}
       type="button"
       onClick={()=>{
                  window.location.href = `https://accounts.google.com/o/oauth2/v2/auth
                                          /oauthchooseaccount?
                                          redirect_uri=${GOOGLE_REDIRECT_URI}
                                          &prompt=consent
                                          &response_type=code
                                          &client_id=${GOOGLE_CLIENT_ID}
                                          &scope=${GOOGLE_LOGIN_SCOPE}`
                }}           
       >

So in the start our user will click the sign in / sign up button and will be redirected to the authorization server which will handle the remaining part of authentication .

which will look some thing like this -

once the user authenticates with our auth provider they will be guided to consent page .

Now once user provides the consent , they will be redirected to callback or redirect uri ( with auth code as url param ) , in this case we are keeping a frontend or client side uri as redirect uri .

Then from frontend we will send the auth code to our web server via POST request .

while we get the response from our server , our client will see a loading screen .

export function OAuthPage() {

  const navigate = useNavigate();

  const oauthHandler = useCallback(async () => {
    const searchParams = new URLSearchParams(window.location.search);

    for (const [key, value] of searchParams) {
        if(key == "code"){
           try {
            await axios.post(`${import.meta.env.VITE_BACKEND_URI}/v1/auth/googleOAuth`,{
                 authorizationCode : value
           },{
            withCredentials:true
           })

           navigate("/");
           } catch (error) {
            console.log(error)
           }

           return ;
        }else if(key=="error"){
           navigate("/auth/google/error")
        }
    }

  }, [navigate])


  useEffect(() => {
    oauthHandler()
  }, [oauthHandler]);

  return (
    <div>
      <Loader/>
    </div>
  )
}

Now as the web server gets the auth code , it does the following -

const oAuthHandler = async (req:Request,res:Response) => {

    const { authorizationCode } = req.body;

    try {

    if(!authorizationCode) throw new ApiError(401,"authorization code absent") ;
    const googleAuthorizationServer = "https://oauth2.googleapis.com/token";
    const httpMethod = "POST";

      const tokenRes = await fetch(googleAuthorizationServer,{
        method:httpMethod,
        headers:{"Content-Type": "application/x-www-form-urlencoded"},
        body:new URLSearchParams({
            code:authorizationCode,
            client_id:process.env.GOOGLE_CLIENT_ID!,
            client_secret:process.env.GOOGLE_CLIENT_SECRET!,
            redirect_uri:`${process.env.ORIGIN}/auth/google/callback`,
            grant_type: "authorization_code",
        })
      }) // 1

      const token = await tokenRes.json();

      const googleAccessToken = token.access_token;

      // fetch user info 

      const userProfile = await fetch("https://www.googleapis.com/oauth2/v2/userinfo",{
         headers:{
            Authorization:`Bearer ${googleAccessToken}`
         }
      }) // 2

      const userInfo:userInfoType = await userProfile.json();

      const user = await db.user.upsert({
           where:{
              email:userInfo.email,
           },
           update:{
              googleId:userInfo.id,
              authType: userInfo.authType === "PasswordLogin" ? "Both" : "GoogleLogin" ,
           },
           create:{
              name:userInfo.name,
              email:userInfo.email,
              authType:"GoogleLogin",
              googleId:userInfo.id,
           }
      }); // 3


      const accessToken = generateAccessToken(user.id);
      const refreshToken = generateRefreshToken(user.id);

      const loggedInUser = await db.user.update({
            where : {
                id : user.id
            },
            data:{
                refreshToken
            }
        });

       return res
        .status(201)
        .cookie("accessToken",accessToken,accessTokenCookieOption)
        .cookie("refreshToken",refreshToken,refreshTokenCookieOption)
        .json({
            message:"user logged in",
            data: loggedInUser
        }) // 4



    } catch (error:any) {
        const err : ApiErrorTypes = error as ApiErrorTypes ;

        const statusCode = typeof err.status === "number" ? err.status : 501 ; 
              return res
              .status(statusCode)
              .json({
                  message:err.message,
                  status:"fail"
              })  
    }
}

So our web server will do basically 4 things -

1. Get the access token from the auth provider by sending a POST request to the authorization server with the auth code, other credentials, and the client secret, which is kept only on the web server to prevent exposure on the client side.

2. Fetch the user data from the resource server using the access token( provided by the authorization server ) .

3. Upsert the user data in the database. If the user previously logged in using the PasswordLogin method, mark the user’s authType as Both; otherwise, set it to GoogleLogin.

4. Generate the access and refresh tokens, store the refresh token in the database, and set both tokens as cookies in the browser.

Once the cookies are set in the browser, the user is considered logged in. This is essentially how the OAuth/OIDC protocol is handled for authentication.

Now as promised earlier , we will discuss two other functionality -

1. Enabling users who signed up with GoogleLogin to also add password-based authentication to their account.

   

    const openIdPasswordAdditionAndChange = async (req:Request,res:Response) => {
         try {
   
            // switch to email - password or just change password 
   
            const { newPassword , changeMode , id } = req.body ;
   
            if(!newPassword) throw new ApiError(400,"password cannot be empty");
   
            const passwordHash = await bcrypt.hash(newPassword,10);
   
            let userData ;
            if(!changeMode){
                 userData = await db.user.update({
                    where:{id},
                    data:{
                        passwordHash,
                        googleId:null,
                        authType:"PasswordLogin"
                    }
                 })
            }else{
                userData = await db.user.update({
                    where:{id},
                    data:{
                        passwordHash,
                        authType:"Both"
                    }
                })
            }
   
            return res.status(200).json({
                message:"password change",
                data: userData
   
            })
   
         } catch (error:any) {
            const err : ApiErrorTypes = error as ApiErrorTypes ;
            const statusCode = typeof err.status === "number" ? err.status : 501 ; 
                  return res
                  .status(statusCode)
                  .json({
                      message:err.message,
                      status:"fail"
                  }) 
        }
    }
   

   This endpoint allows users who initially authenticated via Google Login to either add password-based authentication or switch entirely to email–password login.

   If changeMode is enabled, the user retains Google Login and the authType is updated to Both. Otherwise, Google Login is removed and the account is converted to PasswordLogin.

Adding an admin authorization layer that allows viewing all users, and deleting or logging out specific user accounts.

For this , we will first have an admin login form -

and data is sent to the web server for authentication via POST request which will authorize the user , and convert them from user to admin role .

        const { username , password } = req.body;

    if( username !== ADMIN_SECRET_USERNAME || password !== ADMIN_SECRET_PASSWORD)
         throw new ApiError(401,"incorrect admin credentials")

    if(!process.env.ADMIN_SECRET_KEY) 
         throw new ApiError(501,"Admin secret key absent in server")

    const encryptedKey = await bcrypt.hash(process.env.ADMIN_SECRET_KEY,10);

    const adminToken = await generateAdminToken(encryptedKey)

    return res
    .status(201)
    .cookie("adminToken",adminToken,adminCookieOptions)
    .json({
        message : "admin privileges added to the account",
        success : true
    })

Once the user logs in as an admin they will see a dashboard with all the users , their authentication methods and other user data , and will have functionality of deleting or logging out their respective accounts .

Here are the code for all of these functions -

For getting all the users and their data

 const userData = await db.user.findMany({
              select: {
                    id: true,
                    email: true,
                    name: true,
                    createdAt: true,
                    updatedAt: true,
                    authType: true,
                    refreshToken: true,
                }
        });


        return res.status(200)
         .json({
        users : userData,
        success : true 
        })

Logging out specific user , we will send the id of user to logged out and then set their refresh token to null .

        const { id } = req.body ;

        await db.user.update({
            where : { id },
            data : {
                refreshToken:null
            }
        });

        return res.status(201).json({
            message:"user successfully logged out",
            status:"success"
        })

and at last , Delete a specific user account , here we will send the user id via params from the frontend and delete the user completely from the db .

       const userId = req.params.id as string ;

        const user = await db.user.delete({
            where:{
                id:userId
            }
        });


        return res.status(201).json({
            message:"user deleted successfully",
            user:user,
            status:"success"
        })

That’s it for this blog.

If you want to see everything in action, you can check out the live POC here: POC Link

You can also find the complete code on GitHub here : Repo Link

As I mentioned at the end of my last blog, I’m starting a series around authentication and everything that comes with it. This article covered implementing OAuth 2.0 and OpenID Connect end to end, along with real-world considerations like token handling, account linking, and admin-level authorization.

Also, there was a bit of a hiatus of around 2–3 months, which was longer than I had initially planned, mainly due to office work and other commitments. I’m hoping to keep things more consistent going forward.

In the upcoming posts, I’ll dive deeper into topics like OTP-based authentication, magic links, email verification, password recovery, and other common auth flows you’d see in production systems.

Meanwhile, if you want to strengthen your understanding of OAuth 2.0 and OpenID Connect, this video from Okta’s YouTube channel is a great resource: Okta Vid Link

Thanks for reading, and see you in the next one .

OAuth 2.0 / OIDC

Often misinterpreted as one another , OpenID Connect (OIDC) extends OAuth 2.0 by adding an identity layer, allowing applications to verify user identity and obtain basic profile information . But before diving straight into the OpenID rabbit-hole we must first understand what OAuth is , why it was needed , what problems it solved and how OpenID developed on top of it

OAuth

Understanding OAuth would be easier if we understand the problem it solves , Let’s take for example -

Imagine there’s a wallpaper site you love, and you want to share it with your friends over email. Before the advent of OAuth, you would have had to share your email ID and password with that site so it could send emails on your behalf. Doesn’t that sound like a terribly unsafe idea?

To solve this problem, the creator of the wallpaper site can integrate an OAuth provider (like Google) into their app. When you choose to share something, you’ll first be redirected to a login screen from the OAuth provider (if you aren’t already signed in). This step helps the provider confirm that it’s really you.

After that, you’ll see a consent screen asking for your approval. Once you grant permission, the site receives an access token from the authorization server (which also may or may not be associated with the OAuth provider).

Using this access token, the wallpaper site can then access your relevant information from the resource server ( which also may or may not be associated with the OAuth provider). This allows the site to retrieve only the specific data it needs—like your contact list—to send invitation emails to your friends, without ever seeing your password or requesting unnecessary permissions.

One of the companies that had to rely on this “terribly unsafe idea” in the pre-OAuth era was Yelp, as shown in the screenshot below.

To solve the security issues that Yelp (and many other apps) faced before OAuth, the protocol defines authorization grants (also called flows) — these are the different methods by which a client obtains permission (a credential) to access protected resources.

Each grant type is optimized for certain use-cases. Here are the most common ones:

• Authorization Code — used by web applications with a backend (this is the flow typically used by applications like Yelp) .

• PKCE — an extension of Authorization Code flow, more secure for public clients (e.g. mobile or SPAs) .

• Client Credentials — used in machine-to-machine or server-to-server scenarios (no user interaction) .

• Device Code — used by devices with limited input (e.g. smart TVs) where the user enters a code via another device .

• Refresh Token — allows renewing an expired access token without prompting the user again.

In our discussion, we’ll focus on the Authorization Code grant , since that’s the most relevant for web apps like Yelp. The other grant types will be covered in later articles.

To understand how this code flow will work first we have to understand all the Stakeholders in this workflow and the role they play ,

Client ( The Third-Party Application )

The client is the application that is attempting to get access to the user's account. It needs to get permission from the user before it can do so.

The Resource Server

The resource server is the API server used to access the user's information.

The Authorization Server

This is the server that presents the interface where the user approves or denies the request. In smaller implementations, this may be the same server as the API server, but larger scale deployments will often build this as a separate component.

Resource Owner ( The User )

The resource owner is the person who is giving access to some portion of their account.

When we register our app in any OAuth provider ( like google ) , we are given some credentials ( Client ID and optionally Client Secret ) whereas we register some credentials ( Redirect URI ) from our end in the OAuth provider’s console , lets get into them one by one -

Redirect URIs

The service will only redirect users to a registered URI ( with authorization code ), which helps prevent authorization code interception or phishing-style redirection attacks . Any HTTP redirect URIs must be served via HTTPS. This helps prevent tokens from being intercepted during the authorization process.

Client ID and Secret

1. The Client ID uniquely identifies your app and is included in most requests to the authorization server.

2. The Client Secret is a confidential key used by your app to securely exchange the authorization code for an access token. However, in scenarios where the deployed app cannot keep the secret confidential — such as in Single Page Applications (SPAs) or native mobile apps — the secret should not be used (and ideally, it should not even be issued). In such cases, OAuth providers generally adopt alternate protections (for example, using PKCE, which removes the need to send a client secret) to maintain security.

Now as we have discussed all the terms and have developed the basic understanding of them lets get deep into the code flow -

• Create a login link that takes the user to the authorization server’s login page (authorization endpoint) to sign in and approve access.

    https://authorization-server.com/auth?response_type=code&client_id=CLIENT_ID&
    redirect_uri=REDIRECT_URI&scope=contacts&state=foo
  

  here lets break down each of the query params -

  1. response_type = It simply indicates what kind of response the authorization server should return to the client, depending on which grant type (flow) is being used .

  2. client_id = client_id as discussed earlier this is the id we get from OAuth provider and is used as identification of our app for the authorization server .

  3. redirect_uri = As discussed earlier , specifies the URL to which the user will be redirected after the authorization process is complete. This value must exactly match one of the redirect URIs registered with the OAuth provider; otherwise, the authorization server will return an error response.

  4. scope = The permissions your app is requesting (e.g., access to profile, contacts, or photos) , it can be one or many clubbed together .

  5. state = A random string generated by your application, which is used to verify integrity of response and prevent CSRF attacks , we will see its use later .

• After logging in through whatever method the authorization server supports or wants user to log in with , user sees authorization prompt which might look something like this

  

  User has two options , deny or allow

  first let’s cover the options which doesn’t require much explaining to do deny option -

  User will be redirected to

    https://yelp.com/cb?error=access_denied
  

  Here , we have taken , yelp.com/cb as a sample Redirect URI of yelp for this example ,

  In the case of deny from the user authorization server will redirect user with some kind of access denied message embedded in the params , which can be dealt by application frontend as they like .

  When they click on allow , authorization server redirects to the provided Redirect URI , with authorization code and state in the params

    https://yelp.com/cb?code=AUTHORIZATION_CODE&state=foo
  

  Here

  1. code = The authorization server response with an Authorization Code to the client .

  2. state = The authorization server returns with the state

You should first compare this state value to ensure it matches the one you started with. You can typically store the state value in a cookie or session, and compare it when the user comes back. This helps ensure your redirection endpoint isn't able to be tricked into attempting to exchange arbitrary authorization codes .

• Now as you have checked the state and confirmed that you are getting getting authorization code from the original authorization server from which it is intended to , there is another dilemma , of what to do with the authorization code , till now everything we had done that is every call between our application and authorization server has been done in the front channel ( i.e. through our frontend ) but now as we are dealing with confidential information ( Client Secret and access token ) we cannot do the exchange for access token in the front channel as users browser are at risk with multiple fronts ( for example - some malicious code in any of the browser extension , users tendency to click any of the malicious website ) , so in general we don’t trust user with the sensitive information .

  So we will send the authorization code to our web-server via the frontend , and our server will perform the exchange and then store the access token or the information extracted from the token in our application database based ( or can even perform an action right away like in this case of sending mails to all the contacts and not storing contacts info in database if not needed ) on our needs .

  For this exchange we will trigger a POST request on authorization server’s “/token” endpoint

  which will look something like this

    POST /token HTTP/1.1
    Host: api.authorization-server.com
    Content-Type: application/x-www-form-urlencoded
  
    grant_type=authorization_code&
    code=AUTHORIZATION_CODE&
    redirect_uri=REDIRECT_URI&
    client_id=CLIENT_ID&
    client_secret=CLIENT_SECRET
  

  1. grant_type= The grant type for this flow is authorization_code .

  2. code= This is the code you received earlier in the query string .

  3. redirect_uri= Must be identical to the redirect URI provided in the original call to the authorization server .

  4. client_id= The client ID you received when you first created the application .

  5. client_secret= Since this request is made from server-side code, the secret is included .

     Authorization server will respond with

      {
        "access_token":"access token",
        "expires_in":3600,
      }
     

     an access token , token expiry ( which will tell us when access token will expire ) and in some cases a refresh token ( can be used to get a new access token generated in case the old one expires ) as well , we will keep these confidential tokens in our server side only and wont expose them to the client side . in case of invalid request we will get an error message as response .

• So we will use the access token by sending it to the resource server to get the authorization of doing something on users behalf or getting some of the data regarding user from the resource server .

  Request to resource server will look something like

    GET /userinfo HTTP/1.1
    Host: api.resource-server.com
    Authorization: Bearer ACCESS_TOKEN
  

  So , basically this is almost everything which is to be covered under OAuth in authorization code grant type .

Open ID Connect

As discussed earlier OIDC was built on top of OAuth 2.0 Standard , Primary motive behind introduction of OIDC was to reduce the malpractice that was to use OAuth for authentication purposes , Initially most of the companies used OAuth as work around to implement authentication in their application .

So as a way to streamline the process of authentication Open ID was introduced , there isn’t much difference in code flow of OIDC from OAuth in case of Authorization code grant type .

The main difference is ,

1. There is no other resource server here authorization server is our resource server.

2. An extra openid scope is added to our initial request to authorization server .

3. When we do code — token exchange for access token we get an ID token , which is JWT token , which can be used to extract basic info about the user on the go and as it is JWT it is temper proof .

   The ID Token when decoded comes out in a format somewhat similar to this

    {
      "iss": "https://accounts.google.com",
      "sub": "10769150350006150715113082367",
      "aud": "CLIENT_ID",
      "exp": 1311281970,
      "iat": 1311280970,
      "email": "user@example.com",
      "name": "John Doe"
    }
   

   with some of the important keys here being
   - sub (subject) - unique user identifier

   - iss (issuer) - who issued the token

   - aud (audience) - who the token is for i.e. the client app

   - exp (expiration) - when it expires

4. And if we want to get some more information about the user we can use the access token to get more info from the authorization server.

Apart from this there isn’t much that separate both , basically OpenID was introduced as a way to differentiate the task of authentication and authorization .

I am starting a series on authentication and everything in between , next article will be about implementing OpenId Connect for authentication along with two token authentication , and further will go in details about using implementing OTP and magic links for authentication , email verification and password recovery , I have many things planned for the future of this series . Meanwhile if you want to learn more about OAuth and OpenID Connect , watch this video from okta’s youtube channel

and special thanks to Aaron Parecki and his article on OAuth and OIDC do check it out as well ,

& if you want learn more about the code flow of OAuth and OIDC try Google's OAuth Playground & another OAuth playground directly from OAuth 2.0

The Digital Handshake: Cookies and Tokens

When you log into a website, it's like being handed a digital handshake. This handshake is a set of cookies containing two special keys: the access token and the refresh token.

• Access Token: Think of it as a temporary key to a hotel room - it grants you access but only for a short period.

• Refresh Token: This is akin to a permanent key stored safely. It's used to generate new access tokens.

The Hotel Analogy

Let's use a hotel analogy to understand this better. You're a guest at a hotel. You can't have a permanent room key for security reasons(like it getting stolen). Instead, you get a temporary key (access token) and a permanent key (refresh token). The temporary key is for daily use, and when it expires or gets lost, you use the permanent key at a special desk (the server) to get a new temporary key.

Why Two Keys?

You might wonder why we need both keys. The access token, being short-lived, minimizes security risks. The refresh token, stored securely, ensures that you don't have to repeatedly log in, balancing security with user convenience.

In Practice

Here’s a basic JavaScript example of how token-based authentication might look:

// Example JavaScript code for token-based authentication
// generate refresh and access token 
// here we will generate both refresh tokens and access token 
// and store them in cookie
const generateTokens = async (userId){
    // write function to generate 
    // can be used to generate both accessTokens and refreshTokens
    // or only access Token depending upon the use case
}
const options = {
    httpOnly:true,
    secure:true
// can add expire based on the use case just for simplicity 
// i have used same options for both 
}
const loginHandler = async (req,res){
    // write login logic
    const tokens = await generateTokens(userId);
    // tokens = {accessToken:accessTokenValue,refreshToken:refreshTokenValue}
    return res
    .cookie("accessToken",accessToken,options)
    .cookie("RefreshToken",refreshToken,options)

}
const logoutHandler = async (req,res){
   // varifies user by taking accessToken from the cookie
   // clears cookies
   return res
   .clearCookie('accessToken',options)
   .clearCookie('refreshToken',options)
}

const refreshAccessToken = async (res,res){
   const incomingRefreshToken = req.cookies?.refreshToken || req.body.refreshToken
   const decodedToken = jwt.verify(incomingRefreshToken,jwtSecret);
   const user = await User.findById(decodedToken?.id).select("-password");
   // at each step check for errors 
   if(incomingRefreshToken !== decodedToken?.refreshToken){
   // throw error
}
  // after all the checks are done 
  const {newRefreshToken,accessToken} = await generateTokens(user._id);
  return res
   .clearCookie('accessToken',options)
   .clearCookie('refreshToken',options)
}
// this function generates a new access and refresh token everytime you hit a endpoint

Conclusion

Token-based authentication is like a well-oiled lock and key mechanism, keeping your digital presence secure yet accessible. It's an essential part of modern web development.

Learn More

Interested in diving deeper into web development? Check out codedamn for comprehensive courses or follow Hitesh Choudhary on YouTube for insightful tutorials.