Academic Suite Authentication & Authorization

Source: Dev.to

3.1 Authentication Approach in Academic Suite

Academic Suite uses a stateless authentication approach with JSON Web Token (JWT).

Unlike session‑based authentication (which stores login status in server memory or Redis), JWT stores user information directly inside the token sent by the client with every request.

This approach was chosen because it fits an online‑exam system that has the following characteristics:

• High request volume
• Many users active simultaneously
• Need for horizontal scalability

---

3.2 Why JWT (JSON Web Token)?

JWT provides several important advantages for the context of an online exam system:

Scalability – Token validation does not require a database query on every request. The server simply verifies the token signature, keeping the database load controlled even when thousands of students are active simultaneously.

Stateless – The server does not need to store session state, making the application easier to scale horizontally.

Mobile‑ready – JWT works equally well for web and mobile clients, opening up future client‑development opportunities.

This approach is also consistent with the separated frontend–backend architecture used by Academic Suite.

---

3.3 Authentication Flow

The login process is implemented on the backend, specifically in the file backend/handlers/auth.go.

Broadly speaking, the flow is:

1. Request – The client sends credentials in JSON format: { "email": "...", "password": "..." }.
2. User lookup – The server searches for the user by email in the database.
3. Password verification – The supplied password is verified against the stored hash.
4. Token generation – If the credentials are valid, the server generates a JWT containing user information (claims) and returns it to the client.

The client then includes this token in the Authorization: Bearer header of every subsequent request.

---

Password Security with Bcrypt

Academic Suite never stores passwords in plain‑text. For password hashing, bcrypt is used with a relatively high cost.

// During registration or data seeding
hashed, _ := bcrypt.GenerateFromPassword([]byte("password123"), 14)

// During login
err := bcrypt.CompareHashAndPassword(
    []byte(user.Password),
    []byte(inputPassword),
)

Using bcrypt ensures that even if the database is leaked, the original passwords remain difficult to reconstruct.

---

3.4 Anatomy of JWT & Claims

The JWT generated by the system contains important data in the claims section.

claims := jwt.MapClaims{
    "userId": user.ID,
    "role":   user.Role, // admin, teacher, student
    "exp":    time.Now().Add(time.Hour * 1).Unix(),
}

Information stored in the token includes

• userId – user identification
• role – authorization needs
• exp – token validity time limit

By embedding the role inside the token, the system can check access rights without querying the users table on every request.

---

3.5 Authentication Middleware

To protect API endpoints, Academic Suite uses authentication middleware. The middleware:

1. Retrieves the Authorization: Bearer header.
2. Verifies the JWT signature using the secret key.
3. Extracts userId and role from the claims.
4. Stores that data in the request context for downstream handlers.

Example snippet

c.Locals("userId", claims["userId"])
c.Locals("role", claims["role"])

return c.Next()

Handlers later in the chain can access userId and role without re‑implementing authentication logic.

---

3.6 Role‑Based Access Control (RBAC)

Authentication tells who the user is; authorization determines what the user may do.

Academic Suite implements RBAC with three main roles:

• admin
• teacher
• student

For example, only teacher and admin are allowed to create or manage quizzes.

Role‑check pattern in a handler

func CreateQuiz(c *fiber.Ctx) error {
    role := c.Locals("role").(string)

    if role != "teacher" && role != "admin" {
        return c.Status(403).JSON(fiber.Map{
            "error": "Forbidden",
        })
    }

    // Quiz creation logic …
}

This simple pattern is effective for a system with a limited, well‑defined set of roles.

---

3.7 Security Notes for Production

Before deploying to production, consider the following:

• jwtSecret must not be hard‑coded in source code.
• Store the secret in an environment variable (e.g., JWT_SECRET).
• Set token validity (exp) according to your security requirements.
• Implement a token refresh mechanism if longer sessions are needed.

These steps are crucial to preventing token misuse and maintaining overall system security.

---

Chapter Summary

In this chapter we built the foundation of Academic Suite security through:

• A JWT‑based authentication system (stateless, scalable, mobile‑ready).
• A role‑based authorization mechanism (RBAC) that leverages claims stored in the token.

With solid authentication and authorization in place, the system can safely support the exam features described in earlier chapters.

Nature can only be accessed by authorized users.

In **Chapter 4**, we will begin to enter the functional core of the LMS: **quiz management and question bank**, which serves as the basis for the entire online exam process.