Authentication vs. authorization sering disalahartikan dalam pengembangan aplikasi dan keamanan TI, menyebabkan celah serius meski mekanisme lain sudah ada.
Artikel ini menjelaskan perbedaan mendasar, komponen teknis, kesalahan umum, studi kasus nyata, serta langkah desain dan audit praktis untuk membantu tim memperbaiki kontrol akses serta mengurangi risiko kebocoran izin.
Memahami Perbedaan Authentication vs. Authorization secara Praktis
💻 Mulai Belajar Pemrograman
Belajar pemrograman di Dicoding Academy dan mulai perjalanan Anda sebagai developer profesional.
Daftar SekarangAuthentication adalah proses verifikasi identitas: memastikan kamu benar-benar kamu. Sementara itu, authorization adalah proses memberi atau menolak izin akses ke fitur atau data tertentu. Dalam alur aplikasi modern, pengguna selalu melewati authentication dulu, baru kemudian authorization.
Bayangkan gedung perkantoran. Kunci atau kartu akses di pintu utama adalah authentication, sedangkan izin untuk masuk hanya ke lantai tertentu adalah authorization.
Di dunia aplikasi, identitas bisa dikelola oleh identity provider, seperti layanan OAuth atau SSO, lalu dibuktikan lewat credentials, seperti password atau OTP, dan diterjemahkan menjadi token yang dipakai pada setiap permintaan.
Setelah login dengan username/password, server membuat session token atau JWT. Saat kamu mengakses resource, sistem akan mengecek role, permission, atau scope yang tertulis pada token, access control list, atau role-based access control.
Jika authentication gagal, tidak ada akses sama sekali; jika authorization gagal, kamu terautentikasi, tetapi hanya melihat pesan seperti “forbidden” atau fitur yang tersembunyi, dan di sinilah prinsip least privilege mulai berperan.
Komponen Dasar pada Proses Authentication
Credential dan Komponen Inti
Pada proses authentication, beberapa komponen dasar selalu muncul. Misalnya, jenis credential seperti password, OTP, biometrik, dan sertifikat digital. Selain itu, ada identity provider, authentication server, dan session store.
Peran Identity Provider, Authentication Server, dan Session Store
Identity provider memverifikasi siapa kamu. Sementara itu, authentication server mengelola alur login dan menerbitkan token. Berikutnya, session store menyimpan status login. Penyimpanan ini bisa di server. Alternatifnya, status dikodekan di dalam token seperti JWT.
Metode Authentication yang Umum
Metode yang populer mencakup password-based authentication, MFA, certificate-based authentication, dan SSO. Untuk SSO, protokol yang sering dipakai adalah OpenID Connect atau SAML. Dengan MFA, sistem menggabungkan beberapa faktor. Pertama, sesuatu yang kamu tahu, seperti password. Kedua, sesuatu yang kamu punya, seperti OTP di aplikasi. Ketiga, sesuatu yang kamu adalah, seperti biometrik.
SSO dan Konsekuensi Keamanan
SSO memudahkan pengguna. Pengguna cukup login sekali untuk banyak aplikasi. Namun, SSO juga menambah konsekuensi keamanan. Karena itu, desain trust harus jelas. Selain itu, pemisahan izin antar aplikasi perlu ketat.
Token, Session, dan Refresh Token
Token dan session menjadi penghubung antara identitas dan izin. Contohnya, JWT sering dipakai sebagai access token. JWT berisi klaim tentang pengguna. Di sisi lain, session cookie menyimpan session ID. Lalu, session ID tersebut dipetakan ke data di server.
Refresh token dipakai untuk meminta access token baru. Dengan begitu, pengguna tidak perlu login ulang. Namun, refresh token harus disimpan sangat aman. Selain itu, masa berlakunya perlu dibatasi. Tujuannya untuk mengurangi risiko penyalahgunaan.
Ancaman Umum pada Authentication
Ancaman utama terhadap authentication mencakup phishing, credential stuffing, brute force, dan replay attack. Phishing menipu pengguna agar menyerahkan credential. Sebaliknya, credential stuffing memanfaatkan email dan password yang bocor. Biasanya, kombinasi itu dicoba di banyak situs. Brute force mencoba banyak password secara otomatis. Sementara itu, replay attack menggunakan kembali token sah yang dicuri.
Mitigasi Praktis
Mitigasi praktis mencakup rate limiting, kebijakan password yang kuat, MFA, dan secure storage. Selain itu, rotasi kunci kriptografi juga penting. Rate limiting dan account lockout menekan brute force dan credential stuffing. Di sisi lain, MFA membantu saat password sudah bocor.
Penyimpanan password wajib memakai hashing adaptif. Contohnya bcrypt atau Argon2. Terakhir, kunci penandatangan JWT perlu dirotasi secara teratur. Dengan cara ini, dampak kebocoran kunci bisa dibatasi.
Model Authorization dan Kontrol Akses yang Sering Digunakan
Setelah identitas terverifikasi lewat authentication, barulah model authorization menentukan hal yang boleh dilakukan pengguna. Di sini, kamu perlu membedakan identitas (siapa) dan izin (boleh apa).
Model klasik seperti role based access control (RBAC) memberi izin berdasarkan role, misalnya admin, editor, atau viewer. Setiap role dipetakan ke izin spesifik, seperti read:report atau delete:user. Pengelolaan role yang rapi di organisasi membuat audit jauh lebih mudah.
Untuk domain yang lebih dinamis, attribute based access control (ABAC) menggunakan atribut, seperti departemen, lokasi, atau level risiko. access control list (ACL) mencatat siapa yang boleh mengakses tiap objek, cocok untuk sistem file atau storage.
Pendekatan policy based menyimpan aturan dalam policy engine terpusat sehingga perubahan izin cukup lewat konfigurasi, bukan kode. Dalam arsitektur terdistribusi, policy decision point (PDP) memutuskan izin, sementara policy enforcement point (PEP) di layanan memaksa keputusan itu.
Di dunia token based authorization, seperti OAuth 2, izin direpresentasikan lewat scopes dan claims dalam akses token. Scopes menggambarkan batas akses, misalnya read:orders atau write:profile, sedangkan claims memuat informasi identitas dan atribut, seperti role atau departemen.
Untuk sistem kecil dengan proses bisnis stabil, RBAC sederhana biasanya cukup. Namun ketika aturan bergantung konteks, seperti jam kerja, zona, atau level risiko transaksi, ABAC dan policy based memberi fleksibilitas lebih tanpa meledakkan jumlah role.
Kesalahan Konsep Umum dan Contoh Kasus Nyata
Kesalahan paling umum adalah menganggap authentication otomatis memberi semua authorization yang dibutuhkan. Banyak tim juga memakai akses token sebagai “bukti izin” tanpa cek tambahan pada server.
Ditambah lagi, tanggung jawab authentication dan authorization sering digabung dalam satu layanan sehingga aturan izin sulit diaudit serta mudah salah konfigurasi.
Bayangkan sebuah API internal yang memakai role admin untuk mengelola data pelanggan. Karena role mapping dalam identity provider salah, semua pengguna dari grup tertentu otomatis mendapat admin saat login.
Hasilnya, pengguna biasa bisa menghapus data penting hanya karena tokennya berisi role yang keliru, dan tidak ada cek server-side tambahan sebelum operasi sensitif.
Saat audit, kamu bisa pakai ceklis singkat: (1) Apakah setiap operasi sensitif punya cek authorization eksplisit dalam back-end? (2) Apakah token hanya memuat scope minimum, bukan daftar izin “global”? (3) Apakah aturan role mapping terdokumentasi dan dipisah dari kode aplikasi? (4) Apakah ada logging untuk penolakan akses dan eskalasi izin?
Langkah perbaikan cepat bisa dimulai dari memperbaiki role mapping pada IdP dan menambah cek server-side pada setiap endpoint yang mengubah data.
Batasi scope token menjadi spesifik per aplikasi dan per jenis operasi, bukan satu token untuk semua. Pisahkan layanan authentication dari layanan authorization agar aturan izin bisa dikelola, diuji, dan diaudit secara mandiri.
Desain Sistem Aman untuk Menghindari Kesalahan Konsep
Untuk mencegah kesalahan konsep, mulai dari desain: pisahkan layanan authentication dan authorization. Layanan authentication bisa berupa identity provider atau auth service terpusat yang hanya mengelola identitas dan token.
Layanan authorization dikelola lewat centralized IAM atau policy service yang menyimpan policy akses, bukan dalam tiap layanan kecil. Lapisi dengan defense in depth: validasi di gateway, pada layanan, dan kadang database.
Pola arsitektur yang umum: API gateway menangani authentication dan meneruskan JWT atau akses token. Di dalam, service mesh atau policy enforcement point (PEP) memeriksa authorization ke policy decision point (PDP) eksternal yang mengelola policy.
Terapkan least privilege, gunakan ephemeral credentials, seperti short-lived tokens, serta pisahkan tugas admin akses, admin sistem, dan developer agar tidak ada satu pihak yang memegang semua kunci.
Pada microservices, setiap panggilan antar layanan membawa token yang dicek pada PEP dan dicatat dalam audit log dengan trace id.
Untuk monolit, modul auth tetap dipisah secara logis, dengan middleware yang memeriksa authentication dan authorization pada setiap endpoint, lalu menulis structured log yang bisa ditelusuri. Tracing terpusat membantu tim audit melihat siapa mengakses apa, lewat layanan mana, dan kapan sehingga alur perbaikan insiden jauh lebih terarah.
Panduan Praktis Audit Tes dan Perbaikan untuk Tim
Panduan praktis bisa dimulai dari ceklis audit. Pastikan alur authentication jelas: siapa yang mengeluarkan token, berapa lama berlaku, dan cara refresh-nya. Lanjutkan dengan validasi role dan permission matrix: setiap role punya hak minimum, tidak ada role serba bisa tanpa alasan bisnis yang kuat.
Uji akses tak berwenang dengan mencoba mengakses data milik pengguna lain, mengubah ID dalam URL, atau memanipulasi JWT claims. Audit juga token handling: simpan token dalam httpOnly cookie bila memungkinkan, cek rotasi refresh token, dan pastikan logout benar-benar mencabut sesi.
Untuk testing, buat unit test yang menguji aturan authorization per fungsi, bukan hanya per endpoint. Tambahkan integration test yang menyimulasikan alur nyata, misalnya pengguna biasa mencoba aksi admin. Gunakan automated scans srta penetration test yang fokus pada pola broken authorization, seperti akses horizontal dan vertikal yang bocor.
Rekomendasikan tooling yang bisa mencatat berapa banyak akses ditolak per endpoint, seberapa sering tiap role dipakai, dan mendeteksi anomali pola akses. Metrik ini membantu melihat bahwa prinsip least privilege benar-benar berjalan atau hanya ada dalam dokumen.
Proses perbaikan sebaiknya terstruktur: prioritaskan temuan dengan dampak terbesar, lakukan patching, lalu jalankan regression testing agar tidak merusak alur lain. Setiap insiden akses berlebih perlu komunikasi yang jelas ke pemangku kepentingan serta pembaruan kebijakan internal, termasuk penyesuaian role, permission, dan prosedur review berkala.
Penutup
Setelah membaca, pembaca akan mampu membedakan konsep authentication dan authorization, mengidentifikasi kesalahan umum, serta menerapkan langkah konkret untuk memperbaiki arsitektur dan proses audit.
Terapkan prinsip least privilege, pemisahan tanggung jawab, dan monitoring berkelanjutan agar sistem lebih aman, mudah dipelihara, serta tahan terhadap eksploitasi izin.
