Untuk mengamankan lapisan autentikasi dan sesi pada aplikasi backend Rust, publikasi ini langsung menjelaskan strategi praktis yang mencakup validasi input, hashing password, penyimpanan sesi, dan penanganan secret tanpa menyimpang dari tujuan utama: menjaga kredensial serta alur autentikasi tetap aman dan dapat diaudit.

1. Pondasi Validasi dan Hashing Password

Validasi input harus terjadi sebelum logika autentikasi. Gunakan crate seperti validator untuk pola email, panjang password minimal, dan sanitasi. Jangan lupa menolak permintaan yang gagal validasi dengan respons 422 untuk menghindari ambigu.

Gunakan argon2 dengan konfigurasi yang dapat disesuaikan (memory, iterations) dibandingkan algoritme lama. Contoh kode minimal hashing:

let salt = argon2::password_hash::SaltString::generate(&mut rand::thread_rng());
let password_hash = argon2::Argon2::default()
    .hash_password(password.as_bytes(), &salt)
    .map_err(|e| anyhow!("hash error: {}", e))?
    .to_string();

Selalu simpan hash, bukan plaintext. Untuk verifikasi, gunakan PasswordHash::new lalu Argon2::verify_password. Ini memastikan format hash ditangani dengan benar dan memudahkan rotasi algoritme nanti.

2. Secret Handling dan Penggunaan Secret Type

Jangan letakkan secret API, kunci JWT, atau database password langsung di source code. Gunakan dotenv atau konfigurasi berbasis config yang dibaca di awal aplikasi. Manipulasi secret harus mengandalkan crate seperti secrecy agar memory zeroize saat tidak digunakan lagi.

Contoh pembacaan secret:

#[derive(Deserialize)]
struct Settings {
    database_url: Secret,
    jwt_secret: Secret,
}

let settings: Settings = envy::from_env()?;

Jangan pernah log Secret; gunakan Secret::expose_secret() hanya jika benar-benar diperlukan untuk operasi terbatas.

3. Sesi dan Token Jangka Panjang

Pilih model sesi yang sesuai: sesi server-side (disimpan di database/Redis) atau token JWT. Untuk sesi berbasis token, gunakan refresh token untuk memperpanjang autentikasi tanpa meminta ulang password. Simpan refresh token dalam storage terenkripsi (misalnya Redis + HMAC untuk integritas).

Strateginya:

  • Gunakan refresh token dengan masa berlaku lebih panjang dan rotate setiap kali dipakai. Simpan ID sesi dan counter di database untuk mendeteksi reuse.
  • Simpan akses token di header Authorization, jangan di URL atau storage yang mudah diakses.
  • Terapkan logout dengan menghapus sesi di server dan menandai refresh token invalid.

Contoh minimal rotasi refresh token:

fn rotate_refresh_token(session_id: Uuid, old_token: &str) -> Result {
    let new_token = generate_secure_token();
    let expires_at = Utc::now() + Duration::days(30);
    sqlx::query!(
        "UPDATE sessions SET refresh_token = $1, expires_at = $2 WHERE id = $3 AND refresh_token = $4",
        new_token,
        expires_at,
        session_id,
        old_token
    )
    .execute(&db)
    .await?;
    Ok(new_token)
}

Jika update gagal, tolak permintaan karena kemungkinan serangan replay.

4. Penanganan Abuse dan Proteksi Tambahan

Lapisan autentikasi harus memperhitungkan abuse: rate limiting, monitoring, dan upload validation.

  • Rate limiting: Gunakan middleware di axum (misalnya tower::limit atau Redis-based token bucket) untuk membatasi percobaan login/IP.
  • Upload validation: Limit ukuran file, tipe MIME, dan periksa virus scanner jika memungkinkan. Validasi dilakukan sebelum menyimpan pada storage.
  • Deteksi abuse: Catat setiap event autentikasi gagal, pantau pola abnormals, dan gunakan threshold untuk pemblokiran sementara.

Selain itu, aktifkan fitur seperti lockout sementara setelah beberapa kegagalan, dan pastikan endpoint sensitif hanya tersedia melalui HTTPS.

5. Checklist Operasional Keamanan

  1. Validasi input autentikasi dengan validator dan hatikan status 422.
  2. Gunakan argon2 dan Secret untuk hashing dan penyimpanan secret.
  3. Rotasi refresh token: setiap permintaan menghasilkan token baru dan menyimpan status server-side.
  4. Terapkan rate limiting per-IP atau per-user pada endpoint login/reset password.
  5. Pastikan session storage (Redis/Postgre) dilindungi dengan TLS dan encrypted at rest.
  6. Audit log: tulis event penting tanpa menampilkan secret.

Checklist ini bisa dijadikan bagian dari rutinitas deployment atau audit security mingguan.