JWT Authentication and Role-Based Access Control in LocalHands

LocalHands implements role-based access control for its API, ensuring that each request is authenticated and role-checked before it reaches any business logic. The platform supports three user roles: CLIENT, PROVIDER, and ADMIN. Each role has specific permitted actions - CLIENT can post a Service Order, PROVIDER submits Proposals, and ADMIN manages verification. No actions should cross role boundaries, and no action should be possible without a verified identity behind it.

The login request is validated using a typed DTO (Data Transfer Object) called LoginDto, defined in src/auth/dto/login.dto.ts. The DTO accepts either an email address or a phone number as the identifier field, making it inclusive of users who primarily use phone numbers for identity, such as those tied to MTN MoMo and Orange Money accounts.

The authentication flow is handled by AuthService, located in src/auth/auth.service.ts. The validateUser method attempts to find the user based on the provided identifier (email or phone number) and checks the submitted password against the user's password hash using bcrypt.compare(). The password is never stored in plaintext; instead, a hashed version is stored securely. The hash is stripped before returning, ensuring it does not travel beyond the authentication layer.

Upon successful login, the AuthService updates the user's last login timestamp via updateLastLogin(). A JWT (JSON Web Token) payload is then created, containing the user's email, phone number, ID, name, and role. This payload is used to generate the JWT, which is returned to the client along with the access token. The JWT strategy, defined in src/auth/jwt.strategy.ts, validates the token during subsequent requests and reads the role field to make authorization decisions.