Alur OAuth 2.0

OAuth 2.0 adalah kerangka kerja otorisasi terdelegasi. OAuth memungkinkan pengguna memberikan akses terbatas kepada aplikasi pihak ketiga ke sumber daya mereka pada layanan lain tanpa membagikan kata sandi.

• OAuth berkaitan dengan otorisasi (apa yang boleh dilakukan aplikasi), bukan autentikasi (siapa pengguna tersebut).
• Aplikasi menerima access_token dengan cakupan tertentu, bukan kredensial pengguna.

Pihak yang bertahan harus mengingat: OAuth saja tidak membuktikan identitas. Menganggap token akses sebagai bukti masuk adalah kesalahan klasik yang ditangani oleh OIDC.

Setiap alur OAuth melibatkan empat peran. Memetakan peran ini dengan benar sangat penting untuk pemodelan ancaman.

• Pemilik Sumber Daya pengguna yang memiliki data.
• Klien aplikasi yang meminta akses.
• Server Otorisasi (AS) menerbitkan token setelah persetujuan.
• Server Sumber Daya (RS) API yang menyimpan data terlindungi dan memvalidasi token.

Batas kepercayaan berada di antara peran-peran ini. Klien yang disusupi atau AS yang terlalu permisif akan melemahkan seluruh rantai.

Pemberian Kode Otorisasi adalah alur yang direkomendasikan untuk aplikasi web dan seluler. Alur ini memisahkan pengalihan yang terlihat oleh pengguna dari pertukaran token rahasia.

• Pengguna dialihkan ke AS untuk melakukan autentikasi dan memberikan persetujuan.
• AS mengembalikan code yang berumur singkat ke URI pengalihan yang terdaftar.
• Klien menukarkan kode tersebut (di sisi server) dengan token melalui kanal komunikasi terpisah.

Karena token diperoleh melalui kanal komunikasi terpisah, token tidak pernah muncul di bilah alamat atau riwayat peramban.

PKCE (RFC 7636) memperkuat pemberian kode otorisasi dan kini direkomendasikan untuk semua klien, termasuk klien rahasia.

• Klien membuat code_verifier acak dan mengirimkan hashnya sebagai code_challenge.
• Saat pertukaran token, klien harus menyajikan pemverifikasi asli.

Hal ini mengikat kode ke peminta awal sehingga penyerang yang mencegat kode otorisasi tidak dapat menukarkannya.

Pemberian Kredensial Klien ditujukan untuk akses antar mesin ketika tidak ada pengguna yang terlibat (layanan sisi belakang yang memanggil API).

• Klien melakukan autentikasi dengan kredensialnya sendiri dan menerima token akses.
• Biasanya tidak ada persetujuan pengguna maupun token penyegaran.

Batasi cakupan token ini secara ketat dan ganti rahasia klien secara berkala. Jangan pernah menggunakan alur ini untuk menyamar sebagai pengguna akhir.

OAuth menerbitkan dua jenis token utama dengan masa berlaku dan aturan penanganan yang sangat berbeda.

• Token akses berumur singkat dan dikirim ke server sumber daya pada setiap panggilan. Perlakukan token ini sebagai kredensial pembawa.
• Token penyegaran berumur panjang dan hanya digunakan terhadap AS untuk memperoleh token akses baru.

Token penyegaran sangat berharga. Simpan dengan aman, ikat ke klien, dan dukung pencabutan.

Sebagian besar token akses OAuth adalah token bearer: siapa pun yang memegang token dapat menggunakannya, seperti uang tunai.

• Selalu kirimkan melalui TLS; jangan pernah menaruhnya dalam URL karena token dapat bocor ke log dan perujuk.
• Kirimkan melalui header Authorization.
• Pertimbangkan token yang dibatasi pengirim (DPoP, mTLS) untuk API berisiko tinggi.

Pemberian implisit lama mengembalikan token secara langsung dalam fragmen URI pengalihan. Kini pemberian ini tidak dianjurkan oleh OAuth 2.0 Security BCP dan dihapus dalam OAuth 2.1.

• Token bocor melalui riwayat peramban, header perujuk, dan log.
• Tidak adanya saluran belakang menyebabkan autentikasi klien lebih lemah.

Sebagai gantinya, gunakan Kode Otorisasi dengan PKCE untuk SPA.

Parameter state melindungi tahap pengalihan dari CSRF. Klien membuat nilai acak, menyimpannya dalam sesi, lalu memverifikasinya saat panggilan balik.

• Jika state yang dikembalikan tidak cocok, tolak respons tersebut.
• Dengan demikian, penyerang tidak dapat menyisipkan kode otorisasinya sendiri ke dalam sesi korban.

Cakupan menyatakan tingkat perincian akses yang diberikan oleh token. Terapkan hak istimewa minimum di setiap tahap.

• Minta hanya cakupan yang diperlukan fitur tersebut (read:profile, bukan admin).
• Server sumber daya harus menerapkan cakupan pada setiap titik akhir, bukan sekadar memercayai token yang valid.

Persetujuan yang terlalu luas merupakan risiko nyata yang umum: pengguna menyetujui aplikasi yang meminta jauh lebih banyak daripada yang diperlukan.

Sebagian besar insiden OAuth berasal dari konfigurasi, bukan dari protokolnya sendiri.

• Pengalihan terbuka / pencocokan URI pengalihan yang longgar memungkinkan penyerang mencuri kode.
• Tidak adanya state atau PKCE memungkinkan CSRF dan injeksi kode.
• Token akses berumur panjang tanpa pencabutan.
• Memperlakukan token akses sebagai pernyataan autentikasi.

Daftarkan URI pengalihan yang tepat dan validasi dengan ketat.

Kesimpulan utama:

• OAuth 2.0 adalah otorisasi terdelegasi, bukan autentikasi.
• Ada empat peran: pemilik sumber daya, klien, server otorisasi, dan server sumber daya.
• Kode Otorisasi + PKCE adalah pilihan bawaan untuk web, seluler, dan SPA.
• Kredensial Klien digunakan untuk akses antarmesin.
• Lindungi dengan state, pencocokan URI pengalihan yang ketat, token akses berumur pendek, dan TLS di seluruh jalur komunikasi.
• Pemberian implisit dan pemberian kata sandi sudah tidak digunakan lagi.