Autentikasi dan otorisasi adalah konsep berbeda yang sering tertukar. Kekeliruan ini dapat membuat QA mendeskripsikan defect secara salah dan melewatkan risiko akses nyata.
- →Autentikasi bertanya, “Siapa Anda?”
- →Otorisasi bertanya, “Apa yang boleh Anda lakukan?”
Memasukkan nama pengguna dan kata sandi tidak memberikan akses ke setiap sumber daya atau tindakan. Sebaliknya, sebagian sumber daya mungkin tersedia tanpa login tetapi hanya dalam mode terbatas. Uji kedua lapisan secara terpisah.
Autentikasi
Autentikasi mengonfirmasi identitas pengguna, layanan, atau perangkat. Sistem memastikan apakah subjek benar-benar sesuai identitas yang diklaim.
- →Nama pengguna dan kata sandi
- →Kode sekali pakai
- →MFA
- →SSO
- →Access token atau ID token
- →Sertifikat
- →Kredensial antarmesin
Autentikasi mencakup siklus hidup di luar login berhasil:
- →Pengguna atau sistem menyajikan kredensial
- →Server memvalidasinya
- →Sesi dibuat atau token diterbitkan
- →Kredensial memiliki masa berlaku
- →Kredensial dapat kedaluwarsa, dicabut, rusak, atau digunakan dalam konteks salah
Karena itu, pemeriksaan autentikasi biasanya lebih luas daripada percobaan login valid dan tidak valid.
Otorisasi
Setelah sistem mengidentifikasi subjek, otorisasi menentukan tindakan yang diizinkan.
- →Pengguna biasa hanya dapat melihat pesanannya sendiri
- →Manajer dapat melihat pesanan tim
- →Administrator dapat mengubah status pengguna
- →Layanan integrasi dapat membaca data tetapi tidak menghapusnya
- →Pengguna anonim dapat membuka halaman publik tetapi bukan area akun pribadi
Otorisasi mengevaluasi izin, peran, kebijakan, kepemilikan, dan pembatasan bisnis, bukan identitas.
Pengguna yang berhasil terautentikasi tetap dapat tidak memiliki izin untuk suatu tindakan. Ini lapisan kontrol akses tersendiri, bukan kesalahan login.
Mengapa keduanya tertukar
Kegagalannya dapat terlihat serupa dari luar.
- →Pengguna belum login
- →Tokennya kedaluwarsa
- →Tokennya tidak valid
- →Pengguna sudah login tetapi tidak memiliki peran yang diperlukan
- →Pengguna memiliki peran tetapi mencoba membuka sumber daya orang lain
- →Backend memeriksa akses secara salah
UI dapat menampilkan semuanya sebagai “akses ditolak” atau “login diperlukan”. QA harus membedakan defect, penyebab, dan prioritasnya.
Pemeriksaan autentikasi untuk QA
- →Kredensial valid memungkinkan login
- →Kredensial tidak valid tidak memungkinkan login
- →Token dan sesi kedaluwarsa ditangani dengan benar
- →Logout berfungsi dengan benar
- →Logout membatalkan sesi sesuai persyaratan
- →Akses tidak bertahan lebih lama dari yang ditetapkan
- →Remember me, refresh token, MFA, dan SSO bekerja dengan benar
- →Kredensial tidak bocor melalui URL, penyimpanan lokal, log, atau jejak jaringan
- →Login berulang pada perangkat atau tab berbeda berperilaku benar
Uji seluruh siklus hidup kredensial bersama happy path. Banyak defect terjadi saat pembaruan, kedaluwarsa, pencabutan, dan penggunaan ulang token atau sesi, bukan saat login awal.
Pemeriksaan otorisasi untuk QA
- →Pengguna hanya dapat melihat data yang diizinkan
- →Pengguna hanya dapat melakukan tindakan yang diizinkan
- →Backend menegakkan akses, bukan hanya UI
- →ID langsung tidak dapat membuka sumber daya pengguna lain
- →Peran tidak memiliki izin berlebihan
- →Tombol UI tersembunyi tidak tetap dapat dijalankan melalui API
- →Aturan konsisten antara antarmuka web, seluler, dan API
- →Perubahan peran, status, atau keadaan objek tidak memberikan izin secara tidak sengaja
Memeriksa otorisasi hanya melalui UI adalah jebakan umum. Tombol tersembunyi tidak membuktikan perlindungan. Pengujian otorisasi yang efektif hampir selalu melibatkan panggilan API langsung atau setidaknya pemeriksaan respons backend.
Kegagalan umum
- →Mengganti ID dalam request mengungkap data pengguna lain
- →Token pengguna sebelumnya tetap bekerja setelah logout
- →Perubahan peran di antarmuka administrasi tidak segera berlaku
- →Layanan memeriksa peran tetapi tidak kepemilikan objek
- →Frontend menampilkan larangan sementara backend menjalankan request
- →Access token tetap valid lebih lama dari yang diharapkan
- →Peristiwa kritis tidak mencabut refresh token
- →Pengguna anonim menerima lebih banyak data daripada yang diizinkan
Defect ini sering lebih penting bagi kualitas dan keamanan produk daripada masalah UI biasa.
Contoh praktis
Pertimbangkan sistem pesanan.
Pengguna A login dan membuka pesanan #1001, lalu mengganti ID pada request jaringan atau URL menjadi #1002.
Jika sistem mengembalikan pesanan pengguna lain, autentikasi sudah berhasil. Otorisasi gagal karena backend tidak memverifikasi kepemilikan.
Ini pemeriksaan QA yang penting. Login dan penerbitan token dapat bekerja sempurna, tetapi kontrol akses sumber daya yang lemah tetap membuat produk rentan.
Hal penting bagi QA
- →Autentikasi dan otorisasi merupakan lapisan terpisah.
- →Autentikasi memeriksa identitas; otorisasi memeriksa akses.
- →Login berhasil tidak mengizinkan setiap tindakan.
- →Pembatasan UI memerlukan penegakan backend agar memberikan perlindungan andal.
- →Akses ke data dan tindakan pengguna lain adalah area uji penting.
- →Uji siklus hidup token, sesi, dan peran secermat login itu sendiri.
Bacaan lanjutan
- →Dalam basis pengetahuan ini: HTTP dan HTTPS
- →Dalam basis pengetahuan ini: JWT, OAuth 2.0, dan API key
- →Sumber eksternal: OWASP Authorization Cheat Sheet
Matriks peran dan kepemilikan untuk latihan lokal
Pisahkan identitas dari izin mengakses objek tertentu. Dalam fixture pembelajaran lokal, record 1 milik pengguna A dan record 2 milik pengguna B. Pengguna dapat membaca record sendiri; administrator dapat membaca keduanya. String demo-user-a, demo-user-b, dan demo-admin adalah fixture sintetis, bukan kredensial nyata.
Identitas Request Hasil yang diharapkan
Tanpa token GET /records/1 401 dan WWW-Authenticate
Token tidak dikenal GET /records/1 401 dan tidak ada data record
Pengguna A GET /records/1 200, owner a
Pengguna A GET /records/2 403, tanpa kolom owner atau record
Pengguna B GET /records/2 200, owner b
Administrator GET /records/2 200, owner b
Pengguna A POST /items dengan body valid 403 dan tidak ada item baruUntuk objek terlarang, periksa body respons beserta statusnya: kode kesalahan yang disertai data pengguna lain tetap merupakan kegagalan. Respons 401 berkaitan dengan kredensial; 403 berarti operasi ditolak. Produk nyata dapat menggunakan 404 untuk menyembunyikan keberadaan objek, jadi pilih ekspektasi dari kontraknya. Fixture ini sengaja menggunakan 403.
Fixture tidak mengimplementasikan login, verifikasi JWT, kedaluwarsa, pencabutan, atau penyimpanan sesi. Uji mekanisme itu secara terpisah dalam lingkungan berizin; penolakan string asing sembarangan tidak membuktikan bahwa kedaluwarsa token bekerja.
Lanjutkan belajar
Mekanisme token dan kredensial