PKCE: Mengamankan Klien Publik

Tanpa PKCE, aplikasi seluler rentan terhadap serangan intersepsi kode otorisasi. Ketika server otorisasi mengarahkan kode otorisasi ke skema URI khusus yang terdaftar untuk aplikasi, misalnya myapp://callback, aplikasi berbahaya apa pun pada perangkat yang sama yang mendaftarkan skema URI tersebut dapat mencegat pengalihan dan mencuri kode.

Serangannya berlangsung sebagai berikut: aplikasi berbahaya mendaftarkan skema URI khusus yang sama dengan aplikasi yang sah. Ketika server otorisasi mengarahkan kode ke myapp://callback, OS dapat menampilkan kedua aplikasi sebagai penangan. Jika pengguna memilih aplikasi berbahaya atau OS menjadikannya sebagai aplikasi bawaan, penyerang menerima kode otorisasi dan dapat menukarkannya dengan token tanpa mengetahui rahasia klien.

PKCE (RFC 7636) menambahkan rahasia yang dibuat secara dinamis ke alur kode otorisasi. Sebelum memulai alur, klien membuat rangkaian karakter acak yang dihasilkan secara kriptografis, sepanjang 43–128 karakter, yang disebut verifikator kode. Rangkaian ini unik untuk setiap permintaan otorisasi dan tidak pernah dikirimkan sampai tahap pertukaran token.

Klien menghitung tantangan kode dari verifikator: code_challenge = BASE64URL(SHA256(code_verifier)). Penggunaan SHA256 adalah metode yang diwajibkan dalam RFC 7636. Metode "plain", yang mengirimkan verifikator secara langsung, tidak direkomendasikan. Tantangan kode merupakan transformasi satu arah dari verifikator, sehingga mengetahui tantangan tersebut tidak mengungkapkan verifikator.

Permintaan otorisasi menyertakan dua parameter tambahan: "code_challenge=BASE64URL(SHA256(verifier))&code_challenge_method=S256". Server otorisasi menyimpan tantangan kode yang terkait dengan kode otorisasi yang diterbitkan. Tidak ada rahasia yang dikirim ke server yang dapat disadap pada tahap ini.

Selama pertukaran token (POST ke titik akhir token), klien menyertakan "code_verifier=ORIGINAL_RANDOM_STRING" bersama kode otorisasi. Server otorisasi menghitung BASE64URL(SHA256(code_verifier)) dan memverifikasi bahwa hasilnya cocok dengan code_challenge yang tersimpan. Hanya klien sah yang membuat verifikator tersebut yang dapat melewati pemeriksaan ini.

Jika penyerang mencegat kode otorisasi, penyerang hanya menerima kode dan tantangan kode, yang bersifat publik. Untuk menukarkan kode dengan token, penyerang harus memberikan verifikator kode. Karena verifikator dibuat oleh klien yang sah dan tidak pernah dikirimkan sampai pertukaran token, yang berlangsung secara aman, penyerang tidak dapat menghitung atau memperoleh verifikator tersebut.

PKCE juga mencegah serangan penyisipan kode otorisasi, saat penyerang mengganti kode yang valid dengan kode curian dalam pengalihan. Tantangan kode dari kode curian tidak cocok dengan pemverifikasi yang akan diberikan oleh klien korban, sehingga pertukaran token gagal. PKCE memberikan pertahanan berlapis terhadap beberapa vektor serangan secara bersamaan.

Meskipun RFC 7636 awalnya dijelaskan sebagai solusi untuk klien publik (yang tidak memiliki rahasia klien), OAuth Security BCP dan OAuth 2.1 mewajibkan PKCE untuk semua klien, termasuk klien rahasia yang memiliki rahasia klien. PKCE memberikan perlindungan yang independen dari autentikasi klien, sehingga bermanfaat secara universal.

OAuth 2.1 (draft-ietf-oauth-v2-1) menggabungkan praktik terbaik keamanan dari OAuth 2.0 Security BCP ke dalam satu dokumen. OAuth 2.1 mewajibkan PKCE untuk semua alur kode otorisasi, tidak lagi merekomendasikan alur implisit, dan mewajibkan rotasi token penyegaran. PKCE pada dasarnya merupakan dasar wajib untuk setiap implementasi OAuth 2.0 baru.

Mengimplementasikan PKCE dengan benar memerlukan: penggunaan pembangkit bilangan acak yang aman secara kriptografis untuk pemverifikasi (setidaknya 32 byte acak, kemudian dikodekan dalam base64url), penyimpanan pemverifikasi secara aman di klien (bukan di URL atau catatan), penggunaan metode S256 (bukan plain), serta penghapusan pemverifikasi setelah pertukaran token. Sebagian besar pustaka OAuth modern menangani PKCE secara otomatis.

Dalam PKCE, apa hubungan antara pemverifikasi kode dan tantangan kode?

PKCE (RFC 7636) mencegah penyadapan kode otorisasi dengan mengikat setiap kode ke pemverifikasi kode yang dibuat secara dinamis dan hanya diketahui oleh klien yang sah. Pemverifikasi tersebut di-hash untuk menghasilkan tantangan kode (yang dikirimkan secara publik). Pertukaran token memerlukan pemverifikasi asli. PKCE mencegah serangan penyadapan maupun penyisipan. OAuth 2.1 mewajibkan PKCE untuk semua alur kode otorisasi.