Authentication vs Authorization #
Authentication dan authorization adalah dua konsep yang selalu berjalan bersama tapi sangat berbeda. Kebingungan antara keduanya adalah sumber dari banyak celah keamanan — sistem yang mengautentikasi dengan baik tapi mengotorisasi dengan buruk, atau yang mengizinkan akses berdasarkan identitas saja tanpa mempertimbangkan konteks. Memahami perbedaannya secara jelas adalah fondasi untuk merancang sistem yang aman.
Perbedaan yang Jelas #
Authentication (AuthN) — "Siapa kamu?"
→ Memverifikasi identitas
→ Memastikan entitas adalah siapa yang mereka klaim
→ Pertanyaannya: apakah credentials ini valid?
→ Hasilnya: "Ya, ini memang [email protected]"
Authorization (AuthZ) — "Apa yang boleh kamu lakukan?"
→ Menentukan akses berdasarkan identitas yang sudah diverifikasi
→ Pertanyaannya: apakah identitas ini diizinkan melakukan aksi ini?
→ Hasilnya: "alice boleh baca data, tapi tidak boleh hapus"
Urutan yang benar:
Request → Authentication dulu → Authorization kemudian → Akses
Jika authentication gagal → tolak, tidak perlu cek authorization
Jika authentication sukses tapi authorization gagal → tolak dengan 403 Forbidden
Mekanisme Authentication #
Password dan Multi-Factor Authentication #
Password saja — tidak cukup untuk akun cloud:
✗ Password bisa bocor (phishing, credential stuffing, breach)
✗ Password lemah yang di-reuse antar layanan
✗ Tidak ada sinyal kontekstual (login dari mana, kapan)
Multi-Factor Authentication (MFA):
"Sesuatu yang kamu tahu" + "Sesuatu yang kamu punya"
Faktor pertama: password
Faktor kedua: TOTP code (Google Authenticator, Authy)
Hardware key (YubiKey)
Push notification ke device terdaftar
Efektivitas MFA:
→ Mengeliminasi hampir semua credential stuffing attack
→ Password bocor saja tidak cukup untuk login
→ Wajibkan MFA untuk semua akun cloud, terutama yang punya
akses ke production atau IAM management
MFA-resistant phishing (perlu diketahui):
→ Real-time phishing bisa bypass TOTP (attacker relay code)
→ Hardware key (FIDO2/WebAuthn) adalah yang paling tahan
terhadap phishing karena bound ke domain tertentu
API Key dan Access Token #
Long-lived API Key (Access Key):
→ Credentials permanen yang di-generate untuk programmatic access
→ Contoh: AWS Access Key ID + Secret Access Key
Risiko:
✗ Tidak expire — jika bocor, window of exposure permanen
✗ Sering di-hardcode di kode atau config file
✗ Tidak ada konteks — berlaku dari mana saja, kapan saja
Best practice jika harus pakai:
✓ Rotasi secara berkala (minimal 90 hari)
✓ Simpan di secrets manager, tidak di kode
✓ Monitor penggunaan — alert jika digunakan dari lokasi tidak biasa
Short-lived Token (direkomendasikan):
→ Token yang expire setelah periode singkat (1 jam, 12 jam)
→ Di-generate oleh STS (Security Token Service) saat role di-assume
→ Otomatis di-refresh oleh SDK
Keuntungan:
✓ Jika bocor → hanya berbahaya selama sisa masa aktif token
✓ Tidak perlu rotasi manual
✓ Bisa di-scope ke session tertentu
Service-to-Service Authentication #
Tantangan: Bagaimana Service A membuktikan identitasnya ke Service B?
Opsi 1 — Shared Secret (API Key antar service):
→ Service A kirim secret key ke Service B
→ Service B verifikasi secret
✗ Secret harus disimpan di kedua sisi
✗ Sulit di-rotate tanpa koordinasi
✗ Tidak ada konteks tentang siapa yang memanggil
Opsi 2 — JWT (JSON Web Token):
→ Service A generate JWT yang di-sign dengan private key
→ Service B verifikasi signature menggunakan public key
✓ Stateless — Service B tidak butuh database untuk verifikasi
✓ Bisa embed claims (siapa pemanggilnya, kapan expire, scope apa)
✗ Token yang belum expire tidak bisa di-revoke (kecuali pakai denylist)
Opsi 3 — Mutual TLS (mTLS):
→ Kedua sisi punya sertifikat
→ Saat koneksi, keduanya saling verifikasi sertifikat
✓ Sangat kuat — identitas dibuktikan di level TLS
✓ Tidak bisa di-intercept tanpa sertifikat yang valid
✗ Manajemen sertifikat lebih kompleks
Opsi 4 — Cloud-native Service Account:
→ Service running di cloud mendapat token dari metadata service
→ Token di-verify oleh service lain melalui provider API
✓ Tidak ada secret yang perlu di-manage
✓ Terintegrasi dengan IAM provider
✓ Rekomendasi untuk service-to-service dalam satu cloud provider
Model Authorization #
RBAC — Role-Based Access Control #
RBAC: permission diberikan kepada role, bukan langsung ke user.
User di-assign ke role, dan mewarisi permission role tersebut.
Role: "viewer"
Permission: read resource, list resources
Role: "editor"
Permission: read, write, update resources
(bukan turunan dari viewer — didefinisikan ulang)
Role: "admin"
Permission: read, write, update, delete, manage users
User alice → di-assign ke role "editor"
User bob → di-assign ke role "viewer"
User charlie → di-assign ke role "admin"
Keuntungan:
✓ Mudah dikelola — tambah user baru tinggal assign role
✓ Konsisten — semua user dengan role yang sama punya akses sama
✓ Mudah di-audit — lihat role, tahu apa yang bisa dilakukan
Keterbatasan:
✗ Role explosion — terlalu banyak role untuk konteks yang berbeda
✗ Sulit untuk akses kontekstual (waktu, lokasi, kondisi)
ABAC — Attribute-Based Access Control #
ABAC: permission ditentukan berdasarkan atribut dari subject,
resource, action, dan environment.
User attributes: department=engineering, clearance=high
Resource attributes: classification=confidential, owner=engineering
Environment: time=business-hours, location=corporate-network
Policy: izinkan akses jika:
user.department == resource.owner
AND user.clearance >= resource.classification
AND environment.time == "business-hours"
Lebih fleksibel dari RBAC:
✓ Tidak perlu membuat role baru untuk setiap kombinasi
✓ Kontekstual — sama user, akses berbeda di kondisi berbeda
✓ Scalable untuk organisasi besar dengan banyak resource
Lebih kompleks:
✗ Kebijakan lebih sulit ditulis dan di-debug
✗ Evaluasi bisa lebih lambat (banyak atribut yang dievaluasi)
✗ Butuh sistem yang mature untuk manage atribut
Token dan Session Management #
Alur Token-based Authentication yang Aman:
1. User login dengan credentials + MFA
2. Server verifikasi credentials
3. Server issue:
- Access Token (short-lived: 15-60 menit)
- Refresh Token (long-lived: hari/minggu, di-simpan aman)
4. Client gunakan Access Token untuk request
5. Access Token expire → client gunakan Refresh Token untuk minta
Access Token baru
6. Logout → invalidate Refresh Token di server
Access Token vs Refresh Token:
Access Token: pendek, stateless (JWT), dikirim setiap request
Refresh Token: panjang, stateful (disimpan di DB server), jarang dikirim
Kenapa tidak satu token saja yang panjang?
✓ Access token pendek = window kecil jika dicuri
✓ Refresh token panjang tapi jarang dipakai = exposure minimal
✓ Bisa revoke refresh token (logout dari semua device)
✓ Tidak bisa revoke access token yang sudah di-issue (stateless)
→ makanya harus pendek
Ringkasan #
- Authentication memverifikasi siapa, Authorization menentukan apa yang boleh dilakukan — urutan selalu: autentikasi dulu, baru otorisasi.
- MFA wajib untuk semua akun cloud — password saja tidak cukup; hardware key (FIDO2) adalah yang paling tahan terhadap phishing.
- Short-lived token jauh lebih aman dari long-lived API key — credentials yang expire otomatis membatasi window of exposure saat bocor.
- Untuk service-to-service, gunakan cloud-native service account — tidak ada secret yang perlu di-manage, terintegrasi dengan IAM provider.
- RBAC untuk kontrol yang sederhana dan konsisten, ABAC untuk kontrol yang kontekstual dan granular — pilih sesuai kompleksitas kebutuhan.
- Access token pendek + refresh token untuk session management — akses token expire cepat, refresh token memungkinkan perpanjangan session tanpa login ulang.
← Sebelumnya: Least Privilege Berikutnya: Secret Management →