Authentication vs Authorization #

Dalam arsitektur keamanan teknologi informasi dan komputasi cloud, Authentication (Autentikasi / AuthN) dan Authorization (Otorisasi / AuthZ) adalah dua roda penggerak utama yang selalu bekerja secara berdampingan. Meskipun keduanya sering kali diucapkan secara bersamaan atau tertukar dalam diskusi teknis, keduanya mewakili dua proses logika keamanan yang sangat berbeda. Mengacaukan pemahaman di antara keduanya adalah penyebab utama lahirnya berbagai celah keamanan kritis pada aplikasi, seperti celah bypass autentikasi atau manipulasi otorisasi objek (Broken Object-Level Authorization atau BOLA). Memahami batasan tanggung jawab, alur kerja, dan metode penanganan error dari masing-masing konsep adalah fondasi utama bagi kita untuk merancang sistem yang aman di cloud. Artikel ini akan membedah perbedaan mendasar, mekanisme autentikasi modern, pembandingan model otorisasi RBAC vs ABAC, serta siklus hidup pengelolaan token sesi.

Perbedaan Fundamental dan Alur Eksekusi #

Perbedaan mendasar antara kedua konsep ini dapat diringkas ke dalam dua pertanyaan sederhana:

• Authentication (AuthN) menjawab pertanyaan: “Siapa subjek pengakses ini?”. Ini adalah proses pembuktian validitas klaim identitas suatu entitas.
• Authorization (AuthZ) menjawab pertanyaan: “Setelah identitas subjek terverifikasi, tindakan apa saja yang diperbolehkan pada sistem ini?”. Ini adalah proses pengecekan hak akses identitas tersebut terhadap suatu tindakan pada sumber daya tertentu.

flowchart TD
    Client["Klien mengirim Request"] --> AuthN["1. Proses Autentikasi (AuthN)<br>(e.g., Validasi Token JWT)"]
    
    AuthN -- "Gagal (Token Kadaluwarsa / Invalid)" --> Res401["Kembalikan HTTP 401 Unauthorized<br>(Klien tidak teridentifikasi)"]
    AuthN -- "Sukses (Identitas Terverifikasi)" --> AuthZ["2. Proses Otorisasi (AuthZ)<br>(e.g., Cek Hak Akses User)"]
    
    AuthZ -- "Gagal (User tidak memiliki izin)" --> Res403["Kembalikan HTTP 403 Forbidden<br>(Klien teridentifikasi, tapi akses ditolak)"]
    AuthZ -- "Sukses (Izin Cocok)" --> Access["3. Berikan Akses ke Sumber Daya"]

Penanganan Error HTTP Status Codes #

• HTTP 401 Unauthorized (Unauthenticated): Status ini dikembalikan ketika autentikasi gagal atau belum dilakukan. Dari sudut pandang spesifikasi HTTP standar, status ini dinamakan “Unauthorized”, namun secara definisi teknis yang tepat adalah Unauthenticated (Klien belum membuktikan siapa dirinya).
• HTTP 403 Forbidden: Status ini dikembalikan ketika autentikasi telah sukses (kita tahu persis siapa pengakses tersebut), namun setelah dievaluasi, pengakses tersebut tidak memiliki izin hak akses untuk mengeksekusi tindakan yang diminta.

Tabel Komparasi AuthN vs AuthZ #

Mekanisme Autentikasi Modern #

Di lingkungan cloud, metode autentikasi tradisional menggunakan kata sandi statis tunggal sudah dianggap usang karena rentan terhadap serangan peretasan massal (credential stuffing dan phishing).

1. Multi-Factor Authentication (MFA) #

MFA mewajibkan pembuktian identitas menggunakan kombinasi minimal dua dari tiga faktor keamanan berikut:

• Sesuatu yang kita ketahui (Something you know): Password atau PIN.
• Sesuatu yang kita miliki (Something you have): Aplikasi OTP (Google Authenticator), perangkat keras fisik (Hardware Token seperti YubiKey), atau smartphone terdaftar.
• Sesuatu dari diri kita (Something you are): Sidik jari, pemindai wajah (Biometrik).

MFA-Resistant Phishing: Kode OTP sekali pakai (TOTP) yang dikirim lewat SMS atau aplikasi authenticator masih dapat diretas jika peretas melakukan serangan phishing real-time (meneruskan kode OTP ke situs tiruan). Metode yang paling aman saat ini adalah FIDO2 / WebAuthn menggunakan kunci hardware fisik. Kunci ini secara kriptografis terikat (bound) ke nama domain web tertentu, sehingga token tidak akan pernah terkirim ke domain phishing.

2. Kredensial Permanen vs Sementara (Long-lived vs Short-lived) #

• API Key / Access Key (Long-lived): Kunci akses permanen yang sering dibuat developer untuk keperluan scripting. Risiko: Kunci ini tidak memiliki masa kedaluwarsa. Jika peretas berhasil mencuri kunci ini dari file .env di server, mereka memiliki waktu selamanya untuk menyusup ke sistem kita.
• Session Token (Short-lived): Token jangka pendek yang diterbitkan secara dinamis oleh layanan token cloud (STS). Token ini memiliki masa aktif sangat singkat (misal 15 menit hingga 1 jam). Jika token bocor, risiko kerusakan terbatasi oleh waktu kedaluwarsa otomatis tersebut.

3. Autentikasi Antar Layanan (Machine-to-Machine / M2M) #

Dalam arsitektur microservices, autentikasi antar server dilakukan menggunakan metode berikut:

• Mutual TLS (mTLS): Kedua pihak (klien dan server) saling memverifikasi sertifikat digital masing-masing saat jabat tangan TLS (TLS Handshake). Ini adalah metode paling aman untuk arsitektur Zero Trust internal.
• Federasi OIDC: Memungkinkan sistem luar cloud (seperti pipeline CI/CD) membuktikan identitasnya ke cloud menggunakan token JWT jangka pendek yang di-sign oleh provider OIDC terpercaya, meniadakan kebutuhan penyimpanan kunci akses cloud permanen di luar cloud.

Model Otorisasi: RBAC vs ABAC #

Setelah identitas terverifikasi, sistem menggunakan salah satu dari dua model otorisasi utama untuk menyaring hak akses:

1. RBAC (Role-Based Access Control) #

Otorisasi diberikan kepada objek “Role” (Peran), bukan langsung ke pengguna. Pengguna kemudian dimasukkan ke dalam satu atau beberapa Role tersebut untuk mewarisi izinnya.

flowchart TD
    UserA["User: Alice"] -->|"di-assign ke"| RoleDev["Role: Developer"]
    UserB["User: Bob"] -->|"di-assign ke"| RoleAuditor["Role: Security Auditor"]
    
    RoleDev -->|"mewarisi izin"| PermWrite["Izin: Tulis kode, Deploy ke Dev"]
    RoleAuditor -->|"mewarisi izin"| PermRead["Izin: Read-only Audit Logs"]

• Kelebihan: Sangat mudah dipahami, mudah di-audit, dan memiliki siklus hidup administrasi yang sederhana untuk tim berskala kecil hingga menengah.
• Keterbatasan (Role Explosion): Jika tim berkembang dan membutuhkan kondisi akses yang dinamis (misalnya: “Developer A hanya boleh mengakses VM di jam kerja saja, dan hanya di region Jakarta”), kita terpaksa harus membuat puluhan Role baru yang spesifik (Developer-Jakarta-WorkHours, Developer-Singapore-Weekend, dll.). Kondisi ini disebut sebagai ledakan peran (role explosion).

2. ABAC (Attribute-Based Access Control) #

Otorisasi dinamis yang dievaluasi secara real-time berdasarkan kombinasi atribut dari:

• Subject (Atribut pengakses: Departemen, Jabatan, IP Source).
• Resource (Atribut target: Tagging Owner, Klasifikasi Data).
• Action (Atribut tindakan: HTTP Method GET/POST).
• Environment (Atribut lingkungan: Jam Kerja, Lokasi VPN Jaringan).

Formula Evaluasi ABAC:
IZINKAN request jika:
  Subject.Department == Resource.OwnerGroup
  AND Resource.DataClassification == "Confidential"
  AND Subject.SecurityClearance >= 3
  AND Environment.SourceIpInsideCorporateVPN == true

• Kelebihan: Sangat fleksibel, kontekstual, dan mampu menangani aturan izin yang sangat kompleks secara dinamis tanpa perlu menambah jumlah objek Role di sistem.
• Keterbatasan: Menulis kebijakan ABAC membutuhkan keahlian tinggi dan evaluasi atribut yang banyak dapat meningkatkan latensi waktu pemrosesan otorisasi API kita.

Siklus Manajemen Sesi dan Token (Session & Token Lifecycle) #

Dalam pengembangan aplikasi web dan API modern, standar de facto manajemen sesi adalah menggunakan JSON Web Token (JWT).

Untuk menjaga keamanan sesi tanpa membebani performa database, kita wajib menerapkan arsitektur Access Token dan Refresh Token.

sequenceDiagram
    autonumber
    participant Client as Klien Aplikasi
    participant Server as API Gateway / Auth Server
    participant DB as Database Sesi
    
    Client->>Server: Kirim Access Token (Expired)
    Server-->>Client: HTTP 401 Unauthorized (Token Kadaluwarsa)
    
    Client->>Server: Kirim Refresh Token & Minta Token Baru
    Server->>DB: Verifikasi status Refresh Token (Apakah di-revoke?)
    DB-->>Server: Status Valid (Belum di-revoke)
    
    Note over Server: Buat Access Token Baru (Masa aktif 15 Menit)
    Server-->>Client: Kembalikan Access Token Baru & Refresh Token Baru (Rotation)
    
    Client->>Server: Kirim Access Token Baru untuk ambil data
    Server-->>Client: HTTP 200 OK (Data Dikirim)

Komponen Manajemen Token: #

1. Access Token (Short-lived & Stateless):
   • Masa Aktif: Sangat singkat (biasanya 15 hingga 60 menit).
   • Sifat: Stateless. API server tidak perlu memanggil database untuk memvalidasi token ini. Server cukup memvalidasi tanda tangan kriptografi (cryptographic signature) JWT menggunakan kunci publik.
   • Keamanan: Jika peretas berhasil mencuri token ini, durasi bahaya penyalahgunaan terbatas oleh waktu kedaluwarsanya yang sangat cepat.
2. Refresh Token (Long-lived & Stateful):
   • Masa Aktif: Panjang (hari, minggu, atau bulan).
   • Sifat: Stateful. Token ini disimpan dengan aman di database sisi server. Klien hanya mengirimkan token ini ke server autentikasi ketika Access Token sudah kedaluwarsa untuk mendapatkan Access Token baru tanpa memaksa pengguna login ulang.
   • Mekanisme Revokasi (Logout): Jika pengguna menekan tombol logout, atau jika administrator mendeteksi adanya aktivitas mencurigakan, server dapat menghapus atau menandai Refresh Token tersebut sebagai “dibatalkan” (revoked) di database. Saat klien mencoba memperbarui sesi menggunakan Refresh Token tersebut, sistem akan menolak dan memaksa klien login ulang menggunakan password + MFA.
3. Refresh Token Rotation (RTR): Setiap kali klien menukar Refresh Token lama dengan Access Token baru, server autentikasi wajib membatalkan Refresh Token lama tersebut dan mengirimkan Refresh Token baru yang berbeda kembali ke klien. Hal ini menjamin jika peretas berhasil mencuri Refresh Token dari penyimpanan lokal klien, upaya peretas menggunakan Refresh Token lama tersebut akan memicu alarm keamanan di server, membatalkan seluruh sesi login yang ada demi melindungi akun pengguna.

Ringkasan #

• Authentication memvalidasi siapa pengakses (AuthN), sedangkan Authorization mengevaluasi izin akses (AuthZ) — Autentikasi wajib diselesaikan dengan sukses sebelum otorisasi dilakukan.
• Tolak akses dengan HTTP 401 untuk kegagalan autentikasi, dan kembalikan error HTTP 403 Forbidden untuk kegagalan otorisasi guna menyederhanakan pelacakan error aplikasi.
• MFA berbasis kunci fisik FIDO2 adalah pertahanan terkuat saat ini karena kebal terhadap metode serangan phishing real-time.
• Gunakan model RBAC untuk menyederhanakan tata kelola izin tim skala menengah, namun pertimbangkan transisi ke model ABAC jika membutuhkan aturan izin dinamis berbasis konteks atribut.
• Implementasikan pemisahan Access Token dan Refresh Token — gunakan masa aktif access token yang singkat (15-30 menit) dikombinasikan dengan Refresh Token Rotation untuk keamanan sesi.
• Gunakan mTLS atau federasi OIDC untuk autentikasi aman antar layanan (machine-to-machine) guna meminimalkan penyebaran kredensial permanen di server.

← Sebelumnya: Least Privilege   Berikutnya: Secret Management →