Authentication System di Golang dengan Gin, GORM, dan JWT

Awalnya saya mengira authentication hanya soal membuat fitur login dan register. Namun setelah mencoba mengimplementasikannya sendiri, saya mulai menyadari bahwa kesalahan kecil di bagian ini bisa berdampak besar terhadap keamanan aplikasi.

Authentication adalah salah satu komponen penting dalam aplikasi modern. Tanpa sistem login yang aman, aplikasi tidak dapat mengenali pengguna dan berisiko terhadap kebocoran data.

Banyak developer pemula juga sering bingung bagaimana membangun sistem autentikasi yang sederhana tetapi tetap aman dan bisa digunakan di dunia nyata.

Dalam artikel ini, saya akan membagikan bagaimana membangun sistem register dan login menggunakan Golang dengan Gin, GORM, dan JWT, sekaligus menjelaskan beberapa keputusan teknis dan hal-hal yang saya pelajari selama proses implementasi.

Tech Stack & Arsitektur

Saya memilih stack yang seimbang antara kecepatan pengembangan dan performa produksi:

• Gin Gonic: Lightweight dan memiliki performa tinggi untuk REST API.
• GORM & SQLite: Mempercepat manipulasi data tanpa menulis SQL manual, dengan SQLite yang praktis untuk tahap development.
• Bcrypt & JWT: Standar industri untuk hashing password dan autentikasi stateless.

Struktur Project

Agar project lebih terorganisir, saya membaginya ke dalam beberapa bagian:

go-auth/
├── config/
├── handlers/
├── models/
├── utils/
└── main.go

Setiap folder memiliki tanggung jawab masing-masing, seperti konfigurasi, handler request, model database, dan helper function. Pendekatan ini membantu mempermudah pengembangan dan maintenance kedepannya.

Alur Authentication System

Secara sederhana, sistem ini bekerja dengan alur berikut:

1. User melakukan register
2. Password di-hash sebelum disimpan ke database
3. User melakukan login
4. Server memverifikasi password
5. Jika valid, server mengembalikan JWT token

Pendekatan ini sudah cukup untuk digunakan sebagai fondasi sistem autentikasi pada banyak aplikasi modern.

Implementasi Register & Login

Dalam sistem ini terdapat dua proses utama: register dan login.

Register

Pada proses register:

• Data user diterima dari request
• Password di-hash menggunakan bcrypt
• Data disimpan ke database

user.Password, _ = utils.HashPassword(user.Password)

func HashPassword(password string) (string, error) {
bytes, err := bcrypt.GenerateFromPassword([]byte(password), 14)
return string(bytes), err
}

Sebelum disimpan, password akan di-hash menggunakan bcrypt agar tidak tersimpan dalam bentuk asli.

Kenapa bcrypt?

• Menggunakan one-way hashing (tidak bisa dibalik)
• Sudah menjadi standar industri
• Memiliki cost factor untuk mengatur tingkat keamanan

Dengan menggunakan bcrypt sistem tidak benar-benar “mengetahui” password user setelah disimpan. Proses verifikasi dilakukan dengan membandingkan hash bukan dengan mendekripsi password. Di sini saya mulai memahami bahwa keamanan bukan tentang menyembunyikan data, tetapi tentang memastikan data tersebut tidak bisa disalahgunakan bahkan jika terjadi kebocoran.

Login

Pada proses login:

• Sistem mencari user berdasarkan email
• Password diverifikasi menggunakan bcrypt
• Jika valid, sistem menghasilkan JWT token

if err := utils.CheckPassword(user.Password, req.Password); err != nil {
c.JSON(401, gin.H{"error": "Wrong password"})
return
}

Saya sempat mengalami bug di mana login selalu gagal, dan ternyata penyebabnya adalah urutan parameter pada fungsi compare yang terbalik.

Hal kecil seperti ini cukup memakan waktu. Dari situ saya mulai menyadari bahwa di area authentication, bug sering bukan berasal dari logic besar, tetapi dari detail kecil yang terlewat.

Penggunaan JWT

Setelah login berhasil, sistem akan menghasilkan token yang digunakan untuk autentikasi request selanjutnya.

func GenerateJWT(email string) (string, error) {
token := jwt.NewWithClaims(jwt.SigningMethodHS256, jwt.MapClaims{
"email": email,
"exp": time.Now().Add(24 * time.Hour).Unix(),
})
return token.SignedString([]byte("SECRET_KEY"))
}

Kenapa JWT, bukan Session?

1. Stateless: Server tidak perlu menyimpan data di memori/Redis, memudahkan horizontal scaling.
2. Cross-Platform: Sangat kompatibel untuk aplikasi Single Page Application (SPA) maupun Mobile Apps.
3. Trade-off: JWT sulit ditarik kembali (revoke). Solusinya, saya menetapkan waktu kadaluarsa (exp) yang singkat (24 jam) untuk memitigasi risiko jika token bocor.

Kapan JWT tidak cocok?

JWT kurang cocok jika:

• Sistem membutuhkan kontrol session secara real-time
• Perlu melakukan logout paksa (token revoke)
• Aplikasi masih sederhana dan tidak membutuhkan scaling

Dalam kondisi tersebut, session-based authentication bisa menjadi pilihan yang lebih sederhana.

Contoh response saat login berhasil:

{
"token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9…"
}

Token ini kemudian dapat digunakan untuk mengakses endpoint yang dilindungi.

Hasil yang Didapat

Dengan implementasi ini, sistem sudah dapat:

• Register user baru
• Login user
• Menghasilkan JWT token untuk autentikasi

Sistem seperti ini umum digunakan pada aplikasi seperti dashboard admin, e-commerce, maupun aplikasi berbasis SaaS.

Kesimpulan

Membangun authentication system bukan hanya tentang membuat fitur login, tetapi tentang memahami bagaimana menjaga keamanan sistem secara keseluruhan.

Selama proses ini, saya mulai menyadari bahwa setiap keputusan teknis memiliki konsekuensi. JWT memberikan kemudahan dalam scaling, tetapi memiliki keterbatasan dalam kontrol session. bcrypt memberikan keamanan, tetapi juga memiliki dampak terhadap performa.

Di awal, saya hanya fokus pada bagaimana membuat login berhasil. Namun setelah mencoba sendiri, saya mulai melihat bahwa yang lebih penting adalah bagaimana sistem tetap aman saat digunakan di dunia nyata.

Bagi saya, pelajaran terpenting dari implementasi ini adalah: authentication bukan fitur tambahan, tetapi fondasi yang harus dipikirkan sejak awal.

Kedepannya, sistem ini bisa dikembangkan lebih lanjut dengan:

• Middleware untuk protected route
• Refresh token
• Role-based authorization