Wawancara Backend: Bagaimana Anda Menggabungkan OAuth RAR dan DPoP untuk Otorisasi Transaksi?

Pertanyaan dan ruang lingkup

Sebuah klien mobile banking memanggil API pembayaran. Pengguna dapat menyetujui satu transfer sebesar 500 USD ke satu penerima. Server otorisasi harus menampilkan detail transaksi selama proses persetujuan (consent), dan token akses yang disalin tidak boleh dapat digunakan kembali dari instans klien lain. Jelaskan rancangan OAuth 2.0 Rich Authorization Request (RAR) dengan Demonstrating Proof of Possession (DPoP), termasuk penerbitan token, pemeriksaan server sumber daya (resource server), penanganan replay, kehilangan kunci, dan verifikasi.

Ini adalah pertanyaan keamanan backend dan kontrak API. Mata uang, jumlah, dan penerima yang spesifik adalah asumsi wawancara, bukan fakta pasar.

Apa yang sedang diuji oleh pewawancara

Apakah Anda membedakan antara apa yang disetujui pengguna dengan apa yang dapat dipanggil oleh token akses.
Apakah Anda mengetahui bahwa RAR membawa detail otorisasi terstruktur, sedangkan DPoP mengikat token ke suatu kunci dan membuktikan kepemilikan per permintaan.
Apakah setiap titik penegakan disebutkan: server otorisasi, endpoint token, server sumber daya, dan buku besar pembayaran (payment ledger).
Apakah Anda dapat menangani replay, pengiriman duplikat, kehilangan kunci, dan respons penyedia yang ambigu.
Apakah peluncuran (rollout) dan pengujian membuktikan invarian bisnis, bukan hanya memeriksa sintaksis JWT.

Jawaban yang lemah akan mengatakan "masukkan jumlahnya ke dalam scope dan tanda tangani JWT-nya." Jawaban yang kuat menjaga detail transaksi tetap terstruktur, mengikat token yang diterbitkan ke kunci klien, dan menjadikan state machine pembayaran akhir sebagai otoritas utama.

Klarifikasi yang perlu ditanyakan terlebih dahulu

Apakah server otorisasi juga merupakan pemilik buku besar pembayaran? Jika tidak, buku besar harus memeriksa ulang keputusan otorisasi pada saat commit.
Apakah satu otorisasi hanya berlaku untuk tepat satu transfer, atau dapat mengotorisasi serangkaian transfer yang dibatasi? Detail RAR dan masa berlaku token bergantung pada batasan ini.
Bisakah klien seluler mempertahankan kunci yang didukung perangkat keras setelah instalasi ulang, dan bagaimana perangkat yang hilang dicabut aksesnya?
Apakah server sumber daya menerima persyaratan nonce DPoP, dan berapa rentang selisih waktu jam (clock-skew) yang dapat diterima?
Apa yang terjadi setelah batas waktu (timeout) pada penyedia pembayaran: bisakah sistem memeriksa status, atau harus mencatat status tidak diketahui?

Kerangka jawaban 30 detik

"Saya akan menempatkan transfer yang tepat dalam objek authorization_details daripada membuat scope yang luas. Klien membuat pasangan kunci dan mengirimkan bukti DPoP saat meminta token; server otorisasi mengikat token tersebut ke kunci publik tersebut. Server sumber daya memvalidasi token akses, bukti DPoP, metode, URI, stempel waktu, nonce, dan pengikatan kunci-token, lalu meneruskan pengenal transaksi yang diotorisasi ke buku besar pembayaran. Buku besar menerimanya satu kali dengan kunci idempotensi dan mencatat status terminal. Perlindungan replay, pencabutan perangkat, timeout penyedia, dan bukti audit adalah kontrol terpisah, masing-masing diuji pada pemiliknya."

Solusi langkah demi langkah

1. Modelkan tindakan yang diminta

RAR mendefinisikan permintaan authorization_details yang terstruktur. Objek tersebut harus berisi type yang terdaftar, tindakan yang tepat, jumlah, mata uang, pengenal tujuan, dan referensi transaksi. Server otorisasi memvalidasi skema, kepemilikan akun, batas, dan kebijakan sebelum menampilkan persetujuan. Server harus menampilkan nilai kanonikal yang sama dengan yang akan digunakan oleh buku besar; label yang disediakan klien saja tidak cukup.

json

{
  "type": "payment",
  "actions": ["transfer"],
  "amount": "500.00",
  "currency": "USD",
  "beneficiary_id": "b_123",
  "request_id": "rq_7f2"
}

Hasil otorisasi harus merujuk ke catatan otorisasi milik server. Jangan biarkan server sumber daya merekonstruksi uang, mata uang, atau penerima dari string tampilan yang tidak tepercaya.

2. Ikat token ke kunci klien

Klien membuat kunci privat di penyimpanan yang dilindungi dan mengirimkan JWT bukti DPoP ke endpoint token. Bukti tersebut mencakup metode HTTP, URI target, waktu penerbitan, pengenal bukti unik, dan kunci publik. Server otorisasi memeriksa bukti tersebut dan menerbitkan token yang klaim konfirmasinya merujuk ke kunci tersebut. Oleh karena itu, token bearer yang disalin tanpa kunci privat tidak akan cukup untuk melakukan permintaan yang dilindungi.

DPoP adalah pembatasan pengirim tingkat aplikasi; ini tidak menggantikan TLS, penyimpanan kunci yang aman, kebijakan otorisasi, atau pencabutan perangkat. Kunci tersebut merupakan pengautentikasi untuk instans klien, bukan bukti bahwa manusia telah menyetujui pembayaran tertentu.

3. Verifikasi setiap permintaan sumber daya

Klien mengirimkan token akses dan bukti DPoP baru. Server sumber daya memeriksa tanda tangan, kedaluwarsa token, penerbit, audiens, thumbprint konfirmasi, metode, URI, jendela waktu jam, nonce jika diperlukan, dan cache replay pengenal bukti. Server menolak bukti yang digunakan kembali untuk URI lain atau setelah jendela replay-nya habis. Pemeriksaan pengikatan token akses dan pencarian detail otorisasi harus dilakukan bersamaan; bukti yang valid untuk token yang berbeda tidaklah cukup.

4. Jadikan buku besar sebagai otoritas akhir

Server sumber daya membuat perintah pembayaran yang berisi ID catatan otorisasi, intisari (digest) kanonikal jumlah dan penerima, ID instans klien, dan kunci idempotensi. Buku besar membandingkan perintah tersebut dengan catatan yang disetujui dalam satu transaksi. Buku besar hanya menerima otorisasi yang belum digunakan, menulis PENDING atau COMMITTED, dan menolak jumlah yang diubah, tujuan yang berbeda, persetujuan yang kedaluwarsa, atau transisi terminal kedua. Jika penyedia eksternal mengalami timeout, catat UNKNOWN dan lakukan kueri atau rekonsiliasi sebelum mencoba lagi; timeout tidak membuktikan bahwa pemotongan dana tidak terjadi.

5. Tangani pemulihan dan pencabutan

Simpan pengenal bukti untuk jendela replay yang dibatasi dan batasi cache berdasarkan klien dan penerbit. Perangkat yang hilang akan memicu pencabutan kunci atau catatan otorisasinya, bukan hanya sesi peramban. Simpan entri audit untuk hash muatan persetujuan, nilai yang ditampilkan, thumbprint kunci token, keputusan sumber daya, transisi buku besar, dan tindakan operator. Sensor (redact) kunci privat dan token mentah. Peluncuran yang gagal dapat menonaktifkan tipe detail otorisasi baru sambil tetap mempertahankan alur lama yang diatur secara terpisah.

6. Bandingkan alternatif

Scope yang luas seperti payments.write lebih sederhana tetapi tidak dapat mengekspresikan satu jumlah dan satu penerima; buku besar tetap memerlukan otorisasi transaksi tepercaya lainnya. Mutual TLS dapat mengikat token ke sertifikat dan menarik untuk klien server yang terkontrol, tetapi siklus hidup sertifikat perangkat seluler dan terminasi jaringan lebih sulit dikelola. DPoP cocok untuk kunci yang dikelola aplikasi dan klien HTTP, tetapi penanganan nonce, jam, cache replay, dan kehilangan kunci menjadi pekerjaan implementasi yang eksplisit.

Contoh jawaban berkualitas tinggi

"Saya akan memisahkan empat keputusan. Pertama, RAR membawa otorisasi pembayaran berjenis data jelas dengan jumlah, mata uang, penerima, dan ID permintaan server yang tepat; layar persetujuan menampilkan nilai-nilai kanonikal dan server otorisasi memvalidasi batasannya. Kedua, klien seluler menggunakan kunci yang dilindungi dan bukti DPoP, dan token yang diterbitkan diikat ke kunci tersebut. Ketiga, server sumber daya memvalidasi token, bukti, URI, waktu, nonce, dan replay bukti sebelum memuat catatan otorisasi milik server. Terakhir, buku besar pembayaran secara atomik membandingkan catatan tersebut dengan perintah dan mengizinkan satu transisi terminal yang idempoten. Token yang disalin tanpa kunci, penerima yang diubah, bukti duplikat, atau pengiriman kedua akan ditolak. Timeout penyedia menjadi UNKNOWN dan direkonsiliasi, tidak pernah dicoba ulang secara membabi buta. Saya akan mengukur replay yang ditolak, kegagalan nonce, ketidakcocokan otorisasi, perintah duplikat, hasil yang tidak diketahui, dan penyebaran pencabutan, lalu melakukan canary release untuk tipe RAR baru dengan tombol rollback."

Kesalahan umum

Menempatkan jumlah dan penerima dalam scope → scope menjadi string tanpa batas dan kehilangan validasi tipe data → gunakan skema authorization-details terdaftar dan catatan milik server.
Menganggap DPoP sebagai persetujuan manusia → kepemilikan kunci tidak membuktikan apa yang disetujui pengguna → pisahkan antara persetujuan, pengikatan token, dan otorisasi buku besar.
Memvalidasi DPoP hanya di gateway → pemanggil internal atau rute alternatif dapat melewati pemeriksaan → tegakkan pengikatan di setiap batas sumber daya dan teruskan ID keputusan yang ditandatangani.
Mencoba ulang timeout penyedia sebagai pembayaran baru → permintaan pertama mungkin telah berhasil di-commit → kueri status, gunakan kunci idempotensi, dan pertahankan status UNKNOWN yang eksplisit.
Menyimpan cache ID bukti selamanya → memori membengkak dan perubahan kebijakan menjadi sulit dianalisis → gunakan jendela replay terbatas yang terikat pada masa berlaku bukti dan kebijakan jam.

Pertanyaan lanjutan dan tanggapan

Bagaimana jika penyerang mencuri token akses dan bukti DPoP sekaligus?

Tolak penggunaan kembali pengenal bukti dan tegakkan batasan metode, URI, waktu, serta nonce-nya. Buat masa berlaku bukti tetap singkat dan wajibkan bukti baru untuk setiap permintaan. Jika kunci privat juga disusupi, cabut pengikatan kunci dan catatan otorisasi; DPoP sendiri tidak dapat memulihkan kunci yang telah disusupi.

Mengapa tidak menyandikan pembayaran dalam scope JWT?

Scope berguna untuk izin tingkat tinggi (coarse permission), tetapi transfer uang membutuhkan bidang bertipe data, validasi, tampilan, dan catatan server yang stabil. String scope dapat tetap berfungsi sebagai kapabilitas umum sementara RAR dan buku besar menegakkan transaksi yang spesifik.

Bagaimana jika server sumber daya dan server otorisasi tidak sepakat?

Gunakan ID otorisasi milik server dan catatan berversi. Server sumber daya harus menghentikan proses (fail closed) ketika catatan tidak tersedia atau versinya sudah usang untuk tindakan berisiko tinggi. Buku besar memeriksa ulang versi dalam transaksinya, sehingga keputusan lama yang di-cache tidak dapat melakukan commit pada pembayaran yang telah berubah.

Apakah DPoP mencegah semua replay?

Tidak. Ini mengurangi replay token yang disalin saat penyerang tidak memiliki kunci privat dan memungkinkan server mendeteksi bukti yang digunakan kembali. Ini tidak mencegah pemegang kunci yang berniat jahat untuk mengulangi perintah yang diizinkan, sehingga idempotensi buku besar, otorisasi sekali pakai, pembatasan laju (rate limit), dan pencabutan perangkat tetap diperlukan.