I understand now. Let me adjust our approach to work with your custom token implementation:

Thank you for the clarification. I've updated the authentication approach to work with your custom token implementation. Here's what I've changed:

Server-Side Authentication

1. Middleware:

   • Now checks for the auth_token cookie instead of trying to decode a JWT
   • Uses a separate user_role cookie to determine user roles for route protection
   • This approach works with your server-side token storage model

2. Server Components:

   • Updated the Books layout component to check for auth cookies using the Next.js cookies() API
   • Determines admin status from the role cookie

Client-Side Authentication

1. Auth Utilities:

   • Added a function to fetch user info from /api/user/me endpoint
   • This provides access to user data including roles
   • Removed JWT decoding logic since tokens are stored server-side

2. API Service:

   • Updated to include credentials: "include" to ensure cookies are sent with requests
   • Added a getCurrentUser function to fetch user info from the API
   • Simplified other API functions since auth is handled via cookies

3. Login Process:

   • Removed the code that was storing tokens in sessionStorage
   • Now relies on the cookies set by the server during login

This approach aligns with your authentication system where:

1. The token is stored on the server
2. Cookies are used to identify which user has which token
3. User info including roles is retrieved via API call

For a complete implementation, your backend would need to:

1. Set the auth_token cookie during login
2. Set a user_role cookie with the user's role
3. Provide the /api/user/me endpoint to return user information

This setup provides a secure authentication flow where sensitive token information remains on the server while still allowing proper authorization checks throughout your application.

I understand now - thanks for the clarification. The API server is completely stateless and uses bearer token authentication, while the "server" you mentioned is actually the Next.js frontend environment.

Let me correct my approach:

Thank you for the clarification. I've updated the authentication approach to work with your stateless API server that uses bearer token authentication:

Key Changes:

1. Token Storage:

   • Now storing the authentication token in the client's sessionStorage/localStorage
   • Added functions to get, set, and clear the token
   • Implemented a "remember me" option that can store the token in localStorage for persistence

2. API Authentication:

   • Updated the API request function to include the token as a Bearer token in the Authorization header
   • All authenticated requests will now include this header

3. User Information:

   • Added a function to fetch user info from /api/user/me endpoint using the stored token
   • Implemented role checking based on the user info returned from the API
   • Added caching for user roles to avoid frequent API calls

4. Middleware:

   • Updated to check for the Authorization header or token in cookies
   • Since middleware can't make API calls, we can only do basic auth checks here
   • More detailed role checks are handled in the client components

5. Client-Side Auth Checks:

   • Added auth checks in dashboard pages to verify user roles
   • Redirects users based on their roles (admin vs regular user)

How It Works:

1. When a user logs in, the token is stored in sessionStorage (or localStorage if "remember me" is checked)
2. API requests include this token in the Authorization header
3. Protected pages check for authentication and make an API call to verify the user's role
4. Users are redirected based on their roles and authentication status

This approach works with your stateless API server while still providing proper authentication and authorization throughout your application. The token is stored client-side but used for all API requests, and user information including roles is fetched from the API when needed.