Alur Autentikasi
Session, JWT, dan Role

Dari login sampai handler bisnis yang terlindungi

Di online shop skincare, login bukan sekadar mencocokkan email dan password. Login menghasilkan identitas yang aman dipakai ulang oleh setiap request ke /v1/cart, /v1/checkout, dan /v1/admin/products tanpa user harus mengetik ulang kredensialnya.

Di Laravel klasik kamu sering mendapat session begitu saja. Browser menyimpan cookie, server menyimpan data session, lalu middleware auth memutuskan apakah request valid. Pengalaman itu terasa “ajaib” karena banyak hal terjadi di balik layar. Untuk REST API yang melayani React storefront, aplikasi mobile, dan worker internal, kita justru ingin yang sebaliknya: kontrak yang eksplisit. Client mengirim Authorization: Bearer <token> di setiap request yang butuh login, dan server memverifikasinya tanpa menebak.

Pola yang kita pakai adalah pola standar API modern: access token JWT berumur pendek untuk request harian, plus refresh token berumur panjang untuk menukar access token baru tanpa login ulang. Inilah peta endpoint auth yang akan kita bangun, sesuai peta API kanonik proyek skincare.

Dua cara menyimpan bukti login, dengan trade-off berbeda

Session dan token menjawab pertanyaan yang sama: apakah request ini datang dari user yang sudah login? Bedanya ada pada di mana bukti login itu disimpan dan siapa yang memegang state.

Session bukan teknologi usang. Untuk admin panel server-rendered satu domain, session justru lebih sederhana dan logout-nya instan. Tetapi untuk API skincare yang dikonsumsi storefront React, aplikasi mobile, dan webhook pembayaran, token memberi kontrak yang lebih eksplisit dan tidak terikat cookie satu domain.

Header, payload, signature, dan kenapa payload bisa dibaca siapa saja

JWT terlihat seperti satu string acak panjang, padahal ia tiga bagian base64url yang dipisah titik: header.payload.signature. Memahami ketiganya menutup salah satu kesalahan keamanan paling umum.

Header menyebut algoritma signing (mis. HS256). Payload berisi klaim seperti user id, role, issuer, dan expiry. Signature adalah tanda tangan kriptografis yang membuktikan header dan payload tidak diubah sejak token ditandatangani server.

struktur-jwt.txtSalin
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9   <- header  (base64url JSON)
.
eyJ1aWQiOjQyLCJyb2xlIjoiYWRtaW4iLCJleHAiOjE3ODA... <- payload (base64url JSON)
.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c        <- signature (HMAC-SHA256)

Untuk membuktikan payload memang terbuka, kita bisa menulis fungsi kecil yang mengintip payload tanpa verifikasi. Fungsi ini berguna untuk debugging atau menampilkan sisa waktu di UI, tetapi TIDAK boleh dipakai untuk otorisasi.

internal/auth/peek.goSalin
package auth

import (
	"encoding/base64"
	"encoding/json"
	"errors"
	"strings"
)

var ErrMalformedToken = errors.New("token tidak berbentuk header.payload.signature")

// PeekPayload mengintip klaim TANPA memverifikasi signature.
// Hanya untuk debugging atau tampilan. JANGAN dipakai untuk otorisasi.
func PeekPayload(tokenString string) (map[string]any, error) {
	parts := strings.Split(tokenString, ".")
	if len(parts) != 3 {
		return nil, ErrMalformedToken
	}

	raw, err := base64.RawURLEncoding.DecodeString(parts[1])
	if err != nil {
		return nil, err
	}

	var payload map[string]any
	if err := json.Unmarshal(raw, &payload); err != nil {
		return nil, err
	}
	return payload, nil
}

Umur pendek untuk akses, umur panjang untuk sesi, plus rotasi

Pola dua token memisahkan token yang sering berkeliaran dari token yang lebih sensitif. Idenya: kalau access token bocor, kerusakannya hanya bertahan beberapa menit.

Kenapa harus dua token? Karena ada tarik-menarik antara keamanan dan kenyamanan. Access token berumur pendek artinya jendela penyalahgunaan kecil, tetapi user tidak mau login ulang tiap 15 menit. Refresh token menjembatani: ia jarang dikirim (hanya saat access token mati), disimpan lebih hati-hati, dan bisa dicabut sewaktu-waktu.

sequenceDiagram
  participant FE as React Client
  participant API as Go API (chi)
  participant AUTH as Auth Service
  participant DB as Refresh Store
  FE->>API: POST /v1/auth/login (email, password)
  API->>AUTH: verifikasi password (bcrypt)
  AUTH->>DB: simpan hash refresh token + exp
  API-->>FE: 200 access_token (15m) + refresh_token (7h)
  Note over FE,API: request harian pakai access token
  FE->>API: GET /v1/cart (Bearer access_token)
  API->>API: verifikasi JWT di middleware
  API-->>FE: 200 data cart
  Note over FE,API: access token expired
  FE->>API: POST /v1/auth/refresh (refresh_token)
  API->>DB: cek hash, cabut yang lama, simpan yang baru
  API-->>FE: 200 access_token baru + refresh_token baru

Gambar 1. Alur login, akses route terlindungi, dan rotasi token saat access token kedaluwarsa.

Sebuah refresh token sehat melewati daur hidup yang jelas. Memetakannya sebagai state membantu kita memutuskan kapan token boleh dipakai dan kapan harus ditolak.

stateDiagram-v2
  [*] --> Issued: login sukses, hash disimpan
  Issued --> Active: dipakai dalam masa berlaku
  Active --> Refreshed: /auth/refresh sukses (rotasi)
  Refreshed --> Active: token baru jadi yang aktif
  Active --> Expired: lewat 7 hari
  Active --> Revoked: logout atau deteksi kebocoran
  Refreshed --> Revoked: token lama dicabut setelah dirotasi
  Expired --> [*]
  Revoked --> [*]

Gambar 2. Daur hidup refresh token. Token lama selalu beralih ke Revoked begitu dirotasi, sehingga hanya satu token aktif per sesi.

bcrypt dulu, sebelum token bisa diterbitkan

Sebelum menerbitkan token apa pun, login harus memverifikasi password. Dan password tidak pernah disimpan sebagai teks asli, di bahasa apa pun.

Di Laravel, Hash::make() dan Hash::check() melakukan ini untukmu, default-nya bcrypt. Di Go kita memanggil golang.org/x/crypto/bcrypt secara langsung. Idenya identik: simpan hash satu arah, bandingkan saat login, jangan pernah bisa membalik hash menjadi password asli.

internal/auth/password.goSalin
package auth

import "golang.org/x/crypto/bcrypt"

// HashPassword membuat hash bcrypt dari password plaintext saat register.
// Cost 12 menyeimbangkan keamanan dan waktu komputasi pada hardware 2026.
func HashPassword(plain string) (string, error) {
	hash, err := bcrypt.GenerateFromPassword([]byte(plain), 12)
	if err != nil {
		return "", err
	}
	return string(hash), nil
}

// CheckPassword membandingkan password plaintext dengan hash tersimpan.
// Mengembalikan nil bila cocok. Aman terhadap timing attack secara internal.
func CheckPassword(hash, plain string) error {
	return bcrypt.CompareHashAndPassword([]byte(hash), []byte(plain))
}

Saat register, kita hash password lalu simpan user. Saat login, kita ambil user, bandingkan password, baru terbitkan token. Perhatikan model User: field PasswordHash punya JSON tag minus supaya tidak pernah bocor ke response.

internal/user/model.goSalin
package user

type User struct {
	ID           int64  `json:"id"`
	Email        string `json:"email"`
	Role         string `json:"role"` // "customer" atau "admin"
	PasswordHash string `json:"-"`    // minus: JANGAN pernah masuk JSON response
}

github.com/golang-jwt/jwt/v5 dengan klaim kustom dan HS256

Sekarang kita terbitkan access token. Library yang dipakai adalah github.com/golang-jwt/jwt/v5, standar de facto JWT di Go.

Mulai dari go.mod. Proyek skincare menargetkan Go 1.26 dan menambahkan dependency JWT. Versi disetel sesuai blok fakta proyek, bukan ditebak.

go.modSalin
module github.com/kamu/skincare-backend

go 1.26

require (
	github.com/go-chi/chi/v5 v5.3.0
	github.com/go-playground/validator/v10 v10.30.3
	github.com/golang-jwt/jwt/v5 v5.3.1
	golang.org/x/crypto v0.42.0
)

Klaim kustom kita meng-embed jwt.RegisteredClaims (yang membawa exp, iat, iss, sub) lalu menambahkan uid dan role khusus aplikasi. Embedding di Go membuat semua field dan method RegisteredClaims ikut menempel ke Claims tanpa menyalin ulang, mirip menambahkan trait ke sebuah class di PHP.

internal/auth/token.goSalin
package auth

import (
	"errors"
	"fmt"
	"time"

	"github.com/golang-jwt/jwt/v5"
)

const (
	accessTTL  = 15 * time.Minute       // access token ~15 menit
	refreshTTL = 168 * time.Hour        // refresh token ~7 hari
	issuer     = "skincare-backend"     // dicek saat verifikasi
)

var ErrInvalidToken = errors.New("token tidak valid")

// Claims adalah payload JWT access token. Embed RegisteredClaims agar
// exp, iat, iss, sub ikut, lalu tambahkan klaim aplikasi uid dan role.
type Claims struct {
	UserID int64  `json:"uid"`
	Role   string `json:"role"`
	jwt.RegisteredClaims
}

// Issuer menerbitkan access token. Secret dibaca dari env AUTH_JWT_SECRET
// oleh pemanggil dan disuntikkan saat membuat Issuer.
type Issuer struct {
	secret []byte
	now    func() time.Time
}

func NewIssuer(secret string) *Issuer {
	return &Issuer{secret: []byte(secret), now: time.Now}
}

func (iss *Issuer) AccessToken(userID int64, role string) (string, time.Time, error) {
	now := iss.now()
	expiresAt := now.Add(accessTTL)

	claims := Claims{
		UserID: userID,
		Role:   role,
		RegisteredClaims: jwt.RegisteredClaims{
			Subject:   fmt.Sprint(userID),
			Issuer:    issuer,
			IssuedAt:  jwt.NewNumericDate(now),
			ExpiresAt: jwt.NewNumericDate(expiresAt),
		},
	}

	token := jwt.NewWithClaims(jwt.SigningMethodHS256, claims)
	signed, err := token.SignedString(iss.secret)
	if err != nil {
		return "", time.Time{}, fmt.Errorf("sign access token: %w", err)
	}
	return signed, expiresAt, nil
}

Refresh token tidak perlu jadi JWT. Justru lebih aman bila ia string acak tanpa klaim yang bisa dibaca, lalu disimpan sebagai hash. Berikut helper kecil untuk membuat dan menghash refresh token.

internal/auth/refresh.goSalin
package auth

import (
	"crypto/rand"
	"crypto/sha256"
	"encoding/base64"
	"encoding/hex"
)

// NewRefreshToken mengembalikan token plaintext (dikirim ke client) dan
// hash-nya (disimpan di server). Hanya hash yang menetap di database.
func NewRefreshToken() (plain string, hash string, err error) {
	raw := make([]byte, 32)
	if _, err := rand.Read(raw); err != nil {
		return "", "", err
	}
	plain = base64.RawURLEncoding.EncodeToString(raw)
	return plain, HashRefreshToken(plain), nil
}

func HashRefreshToken(token string) string {
	sum := sha256.Sum256([]byte(token))
	return hex.EncodeToString(sum[:])
}

Penjaga pintu yang menolak request sebelum sampai handler bisnis

Middleware auth adalah satpam di lobi. Ia membaca header Authorization, memverifikasi JWT (signature, method, expiry, issuer), lalu menaruh current user ke context. Handler cart dan checkout tidak perlu tahu apa pun soal parsing bearer token.

Verifikasi yang benar memeriksa lebih dari sekadar signature. jwt.ParseWithClaims menerima keyfunc tempat kita WAJIB mengecek bahwa algoritma token adalah HMAC, mencegah serangan algorithm confusion di mana penyerang mengganti alg menjadi none atau menukar HMAC dengan RSA.

internal/auth/verify.goSalin
package auth

import (
	"fmt"

	"github.com/golang-jwt/jwt/v5"
)

func (iss *Issuer) Verify(tokenString string) (*Claims, error) {
	claims := &Claims{}

	keyfunc := func(token *jwt.Token) (any, error) {
		// Tolak token yang bukan HMAC. Mencegah algorithm confusion
		// (mis. penyerang mengganti alg ke "none" atau ke RSA).
		if _, ok := token.Method.(*jwt.SigningMethodHMAC); !ok {
			return nil, fmt.Errorf("metode signing tidak terduga: %v", token.Header["alg"])
		}
		return iss.secret, nil
	}

	token, err := jwt.ParseWithClaims(
		tokenString,
		claims,
		keyfunc,
		jwt.WithValidMethods([]string{"HS256"}),
		jwt.WithIssuer(issuer),
		jwt.WithExpirationRequired(),
	)
	if err != nil || !token.Valid {
		return nil, ErrInvalidToken
	}
	return claims, nil
}

Sekarang middleware-nya. Bentuknya func(http.Handler) http.Handler, sama persis seperti middleware logging dan recoverer di r2c05. Gagal verifikasi berarti 401 unauthorized lewat httpx.Error, memakai envelope yang sudah kita sepakati di r2c04.

internal/auth/middleware.goSalin
package auth

import (
	"net/http"
	"strings"

	"github.com/kamu/skincare-backend/internal/httpx"
)

// Verifier adalah kontrak yang middleware butuhkan, bukan *Issuer konkret.
// Accept interfaces: handler test bisa menyuntik verifier palsu.
type Verifier interface {
	Verify(tokenString string) (*Claims, error)
}

func Middleware(v Verifier) func(http.Handler) http.Handler {
	return func(next http.Handler) http.Handler {
		return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
			raw, ok := bearerToken(r.Header.Get("Authorization"))
			if !ok {
				httpx.Error(w, http.StatusUnauthorized, "unauthorized", "token akses tidak ditemukan")
				return
			}

			claims, err := v.Verify(raw)
			if err != nil {
				httpx.Error(w, http.StatusUnauthorized, "unauthorized", "token akses tidak valid atau kedaluwarsa")
				return
			}

			ctx := withClaims(r.Context(), claims)
			next.ServeHTTP(w, r.WithContext(ctx))
		})
	}
}

func bearerToken(header string) (string, bool) {
	const prefix = "Bearer "
	if !strings.HasPrefix(header, prefix) {
		return "", false
	}
	token := strings.TrimSpace(strings.TrimPrefix(header, prefix))
	return token, token != ""
}

Mengalir dari middleware ke handler tanpa parsing ulang

Setelah token valid, handler butuh cara membaca user aktif tanpa mem-parsing token lagi. Di Go, jalurnya adalah context.Context.

context.Context membawa data request-scoped yang mengalir bersama request. Middleware menaruh *Claims di context, handler membacanya kembali. Kunci context-nya bertipe unexported (type ctxKey int) supaya tidak bisa bertabrakan dengan key dari package lain, sebuah idiom keamanan Go yang penting.

internal/auth/context.goSalin
package auth

import "context"

// ctxKey unexported: package lain tidak bisa menulis atau membaca
// dengan key yang sama, sehingga tidak ada tabrakan kunci context.
type ctxKey int

const claimsKey ctxKey = 0

func withClaims(ctx context.Context, c *Claims) context.Context {
	return context.WithValue(ctx, claimsKey, c)
}

// UserFrom mengambil current user dari context. Mengembalikan ok=false
// bila request tidak melewati middleware auth.
func UserFrom(ctx context.Context) (*Claims, bool) {
	c, ok := ctx.Value(claimsKey).(*Claims)
	return c, ok
}

Handler /v1/me membaca current user dengan auth.UserFrom. Karena route ini sudah dilindungi middleware, ok selalu true, tetapi tetap kita cek sebagai jaring pengaman.

internal/user/handler.goSalin
package user

import (
	"net/http"

	"github.com/kamu/skincare-backend/internal/auth"
	"github.com/kamu/skincare-backend/internal/httpx"
)

type MeResponse struct {
	ID    int64  `json:"id"`
	Email string `json:"email"`
	Role  string `json:"role"`
}

func (h *Handler) Me(w http.ResponseWriter, r *http.Request) {
	claims, ok := auth.UserFrom(r.Context())
	if !ok {
		httpx.Error(w, http.StatusUnauthorized, "unauthorized", "login diperlukan")
		return
	}

	u, err := h.store.ByID(r.Context(), claims.UserID)
	if err != nil {
		httpx.Error(w, http.StatusNotFound, "not_found", "user tidak ditemukan")
		return
	}

	httpx.Data(w, http.StatusOK, MeResponse{
		ID:    u.ID,
		Email: u.Email,
		Role:  u.Role,
	})
}

Autentikasi menjawab siapa, otorisasi menjawab boleh apa

Autentikasi memastikan user benar adanya. Otorisasi memutuskan apa yang boleh ia lakukan. Di skincare, customer boleh checkout, hanya admin boleh membuat produk.

Karena role sudah ada di context (dari claims), middleware RequireRole cukup membaca current user dan membandingkan role-nya. Ia dipasang SETELAH middleware auth, jadi ia bisa berasumsi current user pasti ada. Gagal cocok berarti 403 forbidden, bukan 401.

internal/auth/role.goSalin
package auth

import (
	"net/http"

	"github.com/kamu/skincare-backend/internal/httpx"
)

func RequireRole(role string) func(http.Handler) http.Handler {
	return func(next http.Handler) http.Handler {
		return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
			claims, ok := UserFrom(r.Context())
			if !ok {
				httpx.Error(w, http.StatusUnauthorized, "unauthorized", "login diperlukan")
				return
			}
			if claims.Role != role {
				httpx.Error(w, http.StatusForbidden, "forbidden", "akses ditolak untuk role ini")
				return
			}
			next.ServeHTTP(w, r)
		})
	}
}

Public, customer terlindungi, dan admin dalam satu router

chi membuat pemisahan route publik, route login-required, dan route admin menjadi rapi lewat r.Group dan r.Use. Inilah tempat semua potongan tadi bertemu.

Router memisahkan tiga zona. Route publik (register, login, refresh, webhook) tidak memakai middleware auth. Route customer dibungkus r.Group dengan auth.Middleware. Route admin menambah auth.RequireRole("admin") di atasnya.

internal/router/router.goSalin
package router

import (
	"net/http"

	"github.com/go-chi/chi/v5"
	"github.com/go-chi/chi/v5/middleware"

	"github.com/kamu/skincare-backend/internal/auth"
)

type Deps struct {
	Auth     *auth.Handler
	Verifier auth.Verifier
	Me       http.HandlerFunc
	Cart     http.Handler
	Products http.Handler
	Admin    http.Handler
}

func New(d Deps) http.Handler {
	r := chi.NewRouter()
	r.Use(middleware.RequestID)
	r.Use(middleware.Recoverer)

	r.Route("/v1", func(r chi.Router) {
		// Publik: tidak butuh login.
		r.Post("/auth/register", d.Auth.Register)
		r.Post("/auth/login", d.Auth.Login)
		r.Post("/auth/refresh", d.Auth.Refresh)
		r.Mount("/products", d.Products) // katalog publik (GET)

		// Customer: butuh access token valid.
		r.Group(func(r chi.Router) {
			r.Use(auth.Middleware(d.Verifier))
			r.Get("/me", d.Me)
			r.Mount("/cart", d.Cart)
		})

		// Admin: butuh login DAN role admin.
		r.Group(func(r chi.Router) {
			r.Use(auth.Middleware(d.Verifier))
			r.Use(auth.RequireRole("admin"))
			r.Mount("/admin", d.Admin)
		})
	})

	return r
}

Diagram berikut menelusuri satu request admin dari client sampai ditolak atau diizinkan, melewati dua lapis middleware.

flowchart TD
  REQ([POST /v1/admin/products]) --> AUTH{auth.Middleware:<br/>token valid?}
  AUTH -->|tidak| E401[/401 unauthorized/]
  AUTH -->|ya, taruh Claims di context| ROLE{RequireRole admin:<br/>role cocok?}
  ROLE -->|tidak| E403[/403 forbidden/]
  ROLE -->|ya| H["Handler admin<br/>CreateProduct"]
  H --> OK[/201 Created/]

Gambar 3. Request admin melewati dua gerbang. Token salah berhenti di 401, role kurang berhenti di 403, baru lolos ke handler.

Terakhir, handler Login yang merakit verifikasi password dan penerbitan token. Ia memakai httpx.Data untuk envelope sukses dan httpx.Error untuk kegagalan, konsisten dengan seluruh API.

internal/auth/handler.goSalin
package auth

import (
	"encoding/json"
	"net/http"

	"github.com/kamu/skincare-backend/internal/httpx"
)

type Handler struct {
	store UserStore
	iss   *Issuer
}

type loginRequest struct {
	Email    string `json:"email"`
	Password string `json:"password"`
}

type tokenResponse struct {
	AccessToken  string `json:"access_token"`
	RefreshToken string `json:"refresh_token"`
	TokenType    string `json:"token_type"`
	ExpiresIn    int64  `json:"expires_in"`
}

func (h *Handler) Login(w http.ResponseWriter, r *http.Request) {
	var req loginRequest
	if err := json.NewDecoder(r.Body).Decode(&req); err != nil {
		httpx.Error(w, http.StatusBadRequest, "invalid_json", "body JSON tidak valid")
		return
	}

	u, err := h.store.ByEmail(r.Context(), req.Email)
	if err != nil || CheckPassword(u.PasswordHash, req.Password) != nil {
		// Pesan sama untuk email tak ada maupun password salah.
		httpx.Error(w, http.StatusUnauthorized, "unauthorized", "email atau password salah")
		return
	}

	access, expiresAt, err := h.iss.AccessToken(u.ID, u.Role)
	if err != nil {
		httpx.Error(w, http.StatusInternalServerError, "internal_error", "gagal menerbitkan token")
		return
	}

	refresh, hash, err := NewRefreshToken()
	if err != nil {
		httpx.Error(w, http.StatusInternalServerError, "internal_error", "gagal menerbitkan token")
		return
	}
	if err := h.store.SaveRefresh(r.Context(), u.ID, hash); err != nil {
		httpx.Error(w, http.StatusInternalServerError, "internal_error", "gagal menyimpan sesi")
		return
	}

	httpx.Data(w, http.StatusOK, tokenResponse{
		AccessToken:  access,
		RefreshToken: refresh,
		TokenType:    "Bearer",
		ExpiresIn:    int64(expiresAt.Sub(h.iss.now()).Seconds()),
	})
}

Uji alur dari sudut pandang client React

Setelah route dan middleware tersambung, jalankan alur dari sisi client: pasang dependency, login, akses protected route, lalu refresh saat access token mati.

TerminalSalin
go get github.com/golang-jwt/jwt/v5 golang.org/x/crypto/bcrypt github.com/go-chi/chi/v5
go mod tidy
export AUTH_JWT_SECRET="$(openssl rand -base64 48)"
go run ./cmd/api

Login sebagai admin dan amati pasangan token di response.

TerminalSalin
curl -i -X POST http://localhost:8080/v1/auth/login \
  -H 'Content-Type: application/json' \
  -d '{"email":"admin@skincare.test","password":"rahasia-kuat"}'

200 OK - response loginSalin
{
  "data": {
    "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
    "refresh_token": "q2sgD9vcmcC2k6GlzqTnxDb2iQJt4phtbP75r7bC9BI",
    "token_type": "Bearer",
    "expires_in": 900
  }
}

Pakai access token untuk membuka profil current user.

TerminalSalin
curl -i http://localhost:8080/v1/me \
  -H 'Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...'

Buktikan role-based access: customer yang login membuka route admin harus ditolak 403 forbidden, bukan 401.

TerminalSalin
curl -i -X POST http://localhost:8080/v1/admin/products \
  -H 'Authorization: Bearer TOKEN_CUSTOMER' \
  -H 'Content-Type: application/json' \
  -d '{"name":"Serum Baru","category":"serum","price":189000,"stock":20}'

403 Forbidden - role kurangSalin
{
  "error": {
    "code": "forbidden",
    "message": "akses ditolak untuk role ini"
  }
}

Detail kecil yang melahirkan bug auth di produksi

Auth terlihat sepele saat demo, tetapi sebagian besar insiden keamanan lahir dari detail yang terlewat. Berikut yang paling sering menjerat pendatang dari Express dan Laravel.

Sekarang backend skincare punya alur autentikasi lengkap: register, login, token, middleware, current user, dan role, semuanya memakai envelope dan router yang sudah ada.

Dalam proyek online shop skincare, alur ini menjadi fondasi fitur berikutnya: cart milik user yang login, checkout yang hanya boleh dilakukan customer, admin product management di balik RequireRole, dan webhook pembayaran publik yang memverifikasi signature provider. Di r2c08, kita merakit seluruh peta endpoint ini menjadi satu API yang utuh. Lalu di Roadmap 7, kita memperdalam sisi keamanannya: verifikasi signature webhook, manajemen secrets dan rotasi, cookie hardening, rate limit, dan proteksi endpoint produksi.