OAuth 2.0 PKCE: Cara Kerja dan Mengamankan Login Aplikasi

OAuth 2.0 sering muncul saat aplikasi menawarkan tombol “Masuk dengan akun lain” atau meminta izin untuk mengakses layanan. Agar aplikasi tidak perlu menyimpan kata sandi pengguna, OAuth menggunakan proses pemberian izin dan token. Namun, pada alur Authorization Code, kode otorisasi yang dikirim kembali ke aplikasi tetap perlu dilindungi. Di sinilah PKCE (Proof Key for Code Exchange) berperan: mekanisme tambahan yang membantu memastikan kode tersebut hanya dapat ditukar oleh aplikasi yang memulai proses login.

Apa itu PKCE dan mengapa dibutuhkan?

PKCE adalah ekstensi keamanan untuk OAuth 2.0 yang awalnya dirancang bagi klien publik, seperti aplikasi seluler dan aplikasi web satu halaman (SPA), yang tidak dapat menyimpan rahasia klien dengan aman. Berbeda dari server backend, kode aplikasi yang terpasang pada perangkat pengguna dapat diperiksa, sehingga nilai client secret yang ditanam di dalamnya tidak benar-benar rahasia.

Tanpa perlindungan tambahan, pihak yang berhasil mencegat kode otorisasi berpotensi mencoba menukarnya dengan token akses. PKCE mengikat kode tersebut pada sebuah nilai acak yang dibuat oleh aplikasi saat proses dimulai. Pihak lain yang hanya memperoleh kode otorisasi tidak memiliki nilai pembukti yang dibutuhkan untuk menukarnya.

PKCE bukan pengganti kata sandi, autentikasi multifaktor, atau semua mekanisme keamanan OAuth. Fungsinya lebih spesifik: melindungi pertukaran kode otorisasi agar pencurian kode saja tidak cukup untuk mendapatkan token.

Bagaimana alur Authorization Code dengan PKCE bekerja?

1. Aplikasi membuat verifier. Aplikasi menghasilkan string acak bernama code_verifier menggunakan generator acak yang aman secara kriptografis. Nilai ini disimpan sementara untuk proses yang sedang berlangsung.
2. Aplikasi menghitung challenge. Dengan metode yang direkomendasikan, yaitu S256, aplikasi menghitung hash SHA-256 dari verifier lalu mengubahnya ke format Base64 URL-safe tanpa padding. Hasilnya disebut code_challenge.
3. Pengguna diarahkan ke server otorisasi. Permintaan otorisasi menyertakan code_challenge dan code_challenge_method=S256, bersama parameter OAuth lain seperti client_id, redirect_uri, response_type=code, dan state.
4. Server mengembalikan kode. Setelah pengguna masuk dan memberikan persetujuan bila diperlukan, server mengarahkan kembali pengguna ke URI yang telah didaftarkan, membawa kode otorisasi yang berumur singkat.
5. Aplikasi menukar kode. Aplikasi mengirim kode otorisasi ke endpoint token bersama code_verifier. Server menghitung challenge dari verifier itu dan membandingkannya dengan challenge yang tersimpan pada permintaan awal.
6. Token hanya diberikan jika cocok. Jika verifier sesuai dan pemeriksaan lain lolos, server dapat menerbitkan token. Kode yang dicuri tanpa verifier yang benar tidak dapat ditukar dengan sukses.

Diagram alur OAuth 2.0 membantu menggambarkan pertukaran antara aplikasi, server otorisasi, dan server sumber daya. PKCE menambahkan pemeriksaan pada langkah penukaran kode, bukan mengubah tujuan dasar OAuth.

Mengapa metode S256 lebih disarankan?

PKCE memiliki metode challenge. S256 mengirim hasil hash dari verifier, sedangkan metode plain mengirim verifier itu sendiri sebagai challenge. Menggunakan S256 membuat nilai yang terlihat pada permintaan otorisasi tidak langsung mengungkap verifier. Implementasi baru sebaiknya memilih S256 dan mengikuti dokumentasi penyedia identitas, bukan menurunkan perlindungan demi mengatasi konfigurasi yang keliru.

Verifier perlu dibuat dengan sumber acak yang kuat dan panjang sesuai spesifikasi, bukan dari waktu, nama pengguna, atau angka berurutan. Jangan memakai verifier yang sama untuk beberapa proses login. Nilai tersebut hanya relevan untuk satu transaksi dan harus dibuang setelah proses selesai atau kedaluwarsa.

Kapan PKCE sebaiknya digunakan?

PKCE sangat penting bagi aplikasi Android, iOS, aplikasi desktop, dan SPA yang tidak dapat menjaga rahasia klien. Praktik keamanan OAuth modern juga mendorong penggunaan PKCE secara luas, termasuk pada jenis klien yang memiliki backend. Periksa dukungan penyedia identitas dan pustaka OAuth yang digunakan; jangan merakit protokol sendiri jika pustaka terpelihara tersedia.

OAuth dan OpenID Connect juga perlu dibedakan. OAuth berfokus pada pemberian akses ke sumber daya, sedangkan OpenID Connect menambahkan lapisan identitas untuk proses masuk. Aplikasi yang menggunakan OpenID Connect tetap perlu memvalidasi token identitas sesuai spesifikasi; PKCE sendiri tidak membuktikan seluruh aspek identitas pengguna.

Checklist implementasi yang lebih aman

• Gunakan Authorization Code Flow dengan PKCE dan metode S256.
• Hasilkan verifier memakai generator acak kriptografis dan kaitkan dengan satu transaksi login.
• Daftarkan URI pengalihan yang tepat; hindari pola wildcard yang terlalu luas.
• Gunakan HTTPS untuk endpoint dan callback yang mendukungnya, serta validasi parameter state untuk mengikat respons pada permintaan yang benar.
• Batasi scope sesuai kebutuhan. Jangan meminta akses luas jika aplikasi hanya memerlukan satu fungsi.
• Simpan token dengan aman, atur masa berlaku, dan sediakan mekanisme pencabutan atau rotasi refresh token sesuai kemampuan penyedia.
• Gunakan browser sistem untuk autentikasi aplikasi seluler jika direkomendasikan penyedia, dan hindari memasukkan kredensial ke WebView buatan aplikasi.
• Perbarui pustaka OAuth dan uji skenario gagal, termasuk verifier salah, kode kedaluwarsa, dan URI pengalihan yang tidak cocok.

Masalah umum dan cara menelusurinya

Kesalahan seperti invalid_grant atau kegagalan pertukaran token bisa muncul ketika verifier tidak cocok, kode sudah digunakan, kode kedaluwarsa, atau URI pengalihan berbeda dari permintaan awal. Pastikan aplikasi menyimpan verifier dari transaksi yang sama, tidak memulai ulang proses lalu memakai kode lama, dan mengirim parameter ke endpoint token sesuai dokumentasi penyedia. Hindari mencatat token, verifier, atau kode otorisasi lengkap ke log produksi karena data tersebut dapat disalahgunakan.

PKCE juga tidak melindungi perangkat yang sudah terinfeksi malware, halaman login palsu, token yang bocor setelah diterbitkan, atau izin aplikasi yang terlalu luas. Perlindungan tetap memerlukan validasi sertifikat TLS, pengelolaan token yang benar, pembaruan perangkat, dan pemeriksaan izin yang diberikan. Untuk memahami izin aplikasi yang muncul saat login, baca juga panduan memeriksa OAuth Consent Screen di Nazuaf.com.

Kesimpulan

PKCE menambahkan bukti kriptografis yang mengikat kode otorisasi dengan aplikasi yang memulai proses login. Dengan verifier acak, challenge S256, URI pengalihan yang ketat, dan pengelolaan token yang benar, risiko penyalahgunaan kode yang dicegat dapat dikurangi. PKCE bukan solusi tunggal untuk semua ancaman, tetapi merupakan lapisan penting dalam implementasi OAuth 2.0 dan OpenID Connect yang modern.

Referensi teknis: RFC 7636 — Proof Key for Code Exchange by OAuth Public Clients dan RFC 9700 — Best Current Practice for OAuth 2.0 Security.