Temu Bual Backend: Bagaimanakah Anda Menggabungkan OAuth RAR dan DPoP untuk Pengesahan Transaksi?

Gesaan dan skop

Klien perbankan mudah alih memanggil API pembayaran. Pengguna boleh meluluskan satu pemindahan sebanyak 500 USD kepada seorang penerima. Pelayan pengesahan (authorization server) mesti menunjukkan butiran transaksi semasa kebenaran (consent), dan token akses yang disalin tidak boleh digunakan semula daripada contoh klien lain. Terangkan reka bentuk OAuth 2.0 Rich Authorization Request (RAR) dengan Demonstrating Proof of Possession (DPoP), termasuk pengeluaran token, semakan pelayan sumber, pengendalian ulang tayang, kehilangan kunci dan pengesahan.

Ini ialah soalan keselamatan backend dan kontrak API. Mata wang, jumlah dan penerima yang tepat adalah andaian temu bual, bukan fakta pasaran.

Perkara yang diuji oleh penemu bual

Sama ada anda membezakan perkara yang dipersetujui pengguna daripada perkara yang boleh dipanggil oleh token akses.
Sama ada anda tahu bahawa RAR membawa butiran pengesahan berstruktur, manakala DPoP mengikat token pada kunci dan membuktikan pemilikan bagi setiap permintaan.
Sama ada setiap titik penguatkuasaan dinamakan: pelayan pengesahan, titik akhir token, pelayan sumber dan lejar pembayaran.
Sama ada anda boleh membendung ulang tayang, penyerahan pendua, kehilangan kunci dan respons penyedia yang samar-samar.
Sama ada pelancaran dan ujian membuktikan invarian perniagaan dan bukannya hanya menyemak sintaks JWT.

Jawapan yang lemah menyatakan "letakkan jumlah dalam skop dan tandatangani JWT." Jawapan yang kukuh mengekalkan butiran transaksi berstruktur, mengikat token yang dikeluarkan pada kunci klien, dan menjadikan mesin keadaan pembayaran akhir sebagai pihak berkuasa muktamad.

Penjelasan untuk ditanya terlebih dahulu

Adakah pelayan pengesahan juga pemilik lejar pembayaran? Jika tidak, lejar mesti menyemak semula keputusan pengesahan pada masa komit.
Adakah satu pengesahan sah untuk tepat satu pemindahan, atau bolehkah ia mengesahkan satu set pemindahan yang terhad? Butiran RAR dan jangka hayat token bergantung pada sempadan ini.
Bolehkah klien mudah alih mengekalkan kunci yang disokong perkakasan merentasi pemasangan semula, dan bagaimanakah peranti yang hilang dibatalkan?
Adakah pelayan sumber menerima keperluan nonce DPoP, dan apakah tetingkap herotan jam (clock-skew) yang boleh diterima?
Apakah yang berlaku selepas masa tamat (timeout) pada penyedia pembayaran: bolehkah sistem menanyakan status, atau adakah ia mesti merekodkan keadaan yang tidak diketahui?

Rangka kerja jawapan 30 saat

"Saya akan meletakkan pemindahan yang tepat dalam objek authorization_details dan bukannya mereka cipta skop yang luas. Klien mencipta pasangan kunci dan menghantar bukti DPoP semasa meminta token; pelayan pengesahan mengikat token pada kunci awam tersebut. Pelayan sumber mengesahkan token akses, bukti DPoP, kaedah, URI, cap masa, nonce dan pengikatan kunci token, kemudian menghantar pengecam transaksi yang dibenarkan kepada lejar pembayaran. Lejar menerimanya sekali dengan kunci keidempotennan (idempotency key) dan merekodkan keadaan terminal. Perlindungan ulang tayang, pembatalan peranti, masa tamat penyedia dan bukti audit adalah kawalan berasingan, setiap satu diuji pada pemiliknya."

Penyelesaian langkah demi langkah

1. Modelkan tindakan yang diminta

RAR mentakrifkan permintaan authorization_details berstruktur. Objek harus mengandungi type yang didaftarkan, tindakan yang tepat, jumlah, mata wang, pengecam destinasi dan rujukan transaksi. Pelayan pengesahan mengesahkan skema, pemilikan akaun, had dan dasar sebelum membentangkan kebenaran. Ia mesti memaparkan nilai kanonikal yang sama yang akan digunakan oleh lejar; label yang dibekalkan oleh klien tidak mencukupi.

json

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

Hasil pengesahan harus merujuk rekod pengesahan milik pelayan. Jangan biarkan pelayan sumber membina semula wang, mata wang atau penerima daripada rentetan paparan yang tidak dipercayai.

2. Ikat token pada kunci klien

Klien mencipta kunci peribadi dalam stor yang dilindungi dan menghantar JWT bukti DPoP ke titik akhir token. Bukti merangkumi kaedah HTTP, URI sasaran, masa dikeluarkan, pengecam bukti unik dan kunci awam. Pelayan pengesahan menyemak bukti dan mengeluarkan token yang tuntutan pengesahannya merujuk kunci tersebut. Oleh itu, token pembawa yang disalin tanpa kunci peribadi adalah tidak mencukupi untuk permintaan yang dilindungi.

DPoP ialah kekangan penghantar peringkat aplikasi; ia tidak menggantikan TLS, storan kunci selamat, dasar pengesahan atau pembatalan peranti. Kunci ialah pengesah untuk contoh klien, bukan bukti bahawa manusia telah meluluskan pembayaran tertentu.

3. Sahkan setiap permintaan sumber

Klien menghantar kedua-dua token akses dan bukti DPoP yang baharu. Pelayan sumber menyemak tandatangan, tamat tempoh token, pengeluar, audiens, cap jari pengesahan, kaedah, URI, tetingkap jam, nonce apabila diperlukan dan cache ulang tayang pengecam bukti. Ia menolak bukti yang digunakan semula untuk URI lain atau selepas tetingkap ulang tayangnya. Pengikatan token akses dan carian butiran pengesahan mesti disemak bersama; bukti yang sah untuk token lain adalah tidak mencukupi.

4. Jadikan lejar sebagai pihak berkuasa muktamad

Pelayan sumber mencipta arahan pembayaran yang mengandungi ID rekod pengesahan, ringkasan (digest) kanonikal jumlah dan penerima, ID contoh klien dan kunci keidempotennan. Lejar membandingkan arahan dengan rekod yang diluluskan dalam satu transaksi. Ia hanya menerima pengesahan yang belum digunakan, menulis PENDING atau COMMITTED, dan menolak jumlah yang diubah, destinasi yang berbeza, kelulusan yang telah tamat tempoh atau peralihan terminal kedua. Jika penyedia luaran mengalami masa tamat, rekod UNKNOWN dan tanya status atau selaraskan sebelum mencuba semula; masa tamat tidak membuktikan bahawa tiada caj berlaku.

5. Kendalikan pemulihan dan pembatalan

Simpan pengecam bukti untuk tetingkap ulang tayang yang terhad dan hadkan cache mengikut klien dan pengeluar. Peranti yang hilang membatalkan kunci atau rekod pengesahannya, bukan hanya sesi penyemak imbas. Simpan entri audit untuk cincangan (hash) muatan kebenaran, nilai yang dipaparkan, cap jari kunci token, keputusan sumber, peralihan lejar dan tindakan pengendali. Redak kunci peribadi dan token mentah. Pelancaran yang gagal boleh melumpuhkan jenis butiran pengesahan baharu sambil mengekalkan aliran lama yang ditadbir secara berasingan.

6. Bandingkan alternatif

Skop yang luas seperti payments.write adalah lebih mudah tetapi tidak dapat menyatakan satu jumlah dan satu penerima; lejar tetap memerlukan satu lagi pengesahan transaksi yang dipercayai. Mutual TLS boleh mengikat token pada sijil dan menarik untuk klien pelayan terkawal, tetapi kitaran hayat sijil peranti mudah alih dan penamatan rangkaian adalah lebih sukar. DPoP sesuai dengan kunci yang diuruskan aplikasi dan klien HTTP, tetapi pengendalian nonce, jam, cache ulang tayang dan kehilangan kunci menjadi kerja pelaksanaan yang jelas.

Contoh jawapan berkualiti tinggi

"Saya akan memisahkan empat keputusan. Pertama, RAR membawa pengesahan pembayaran bertaip dengan jumlah tepat, mata wang, penerima dan ID permintaan pelayan; skrin kebenaran memaparkan nilai kanonikal dan pelayan pengesahan mengesahkan had. Kedua, klien mudah alih menggunakan kunci yang dilindungi dan bukti DPoP, dan token yang dikeluarkan diikat pada kunci tersebut. Ketiga, pelayan sumber mengesahkan token, bukti, URI, masa, nonce dan ulang tayang bukti sebelum memuatkan rekod pengesahan milik pelayan. Akhir sekali, lejar pembayaran membandingkan rekod tersebut secara atomik dengan arahan dan membenarkan satu peralihan terminal idempoten. Token yang disalin tanpa kunci, penerima yang diubah, bukti pendua atau penyerahan kedua akan ditolak. Masa tamat penyedia menjadi UNKNOWN dan diselaraskan, tidak sekali-kali dicuba semula secara membabi buta. Saya akan mengukur ulang tayang yang ditolak, kegagalan nonce, ketidakpadanan pengesahan, arahan pendua, hasil yang tidak diketahui dan penyebaran pembatalan, kemudian melancarkan kenari (canary) jenis RAR baharu dengan suis pengunduran (rollback)."

Kesilapan biasa

Meletakkan jumlah dan penerima dalam skop → skop menjadi rentetan tidak terbatas dan kehilangan pengesahan bertaip → gunakan skema authorization-details yang didaftarkan dan rekod milik pelayan.
Memperlakukan DPoP sebagai kebenaran manusia → pemilikan kunci tidak membuktikan perkara yang diluluskan oleh pengguna → pastikan kebenaran, pengikatan token dan pengesahan lejar berasingan.
Mengesahkan DPoP hanya di get laluan (gateway) → pemanggil dalaman atau laluan alternatif mungkin memintas semakan → kuat kuasakan pengikatan pada setiap sempadan sumber dan hantar ID keputusan yang ditandatangani.
Mencuba semula masa tamat penyedia sebagai pembayaran baharu → permintaan pertama mungkin telah dikomit → tanya status, gunakan kunci keidempotennan dan kekalkan keadaan UNKNOWN yang jelas.
Menyimpan cache ID bukti selama-lamanya → memori berkembang dan perubahan dasar menjadi sukar untuk dinilai → gunakan tetingkap ulang tayang terhad yang terikat pada jangka hayat bukti dan dasar jam.

Susulan dan respons

Bagaimana jika penyerang mencuri kedua-dua token akses dan bukti DPoP?

Tolak penggunaan semula pengecam bukti dan kuat kuasakan kekangan kaedah, URI, masa dan nonce. Pastikan jangka hayat bukti pendek dan perlukan bukti baharu bagi setiap permintaan. Jika kunci peribadi juga terjejas, batalkan pengikatan kunci dan rekod pengesahan; DPoP tidak boleh memulihkan kunci yang terjejas dengan sendirinya.

Mengapa tidak mengekod pembayaran dalam skop JWT?

Skop berguna untuk kebenaran kasar, tetapi pemindahan wang memerlukan medan bertaip, pengesahan, paparan dan rekod pelayan yang stabil. Rentetan skop boleh kekal sebagai keupayaan luas manakala RAR dan lejar menguatkuasakan transaksi yang tepat.

Bagaimana jika pelayan sumber dan pelayan pengesahan tidak bersetuju?

Gunakan ID pengesahan milik pelayan dan rekod berversi. Pelayan sumber mesti gagal-tutup (fail closed) apabila rekod tidak tersedia atau versinya sudah lapuk untuk tindakan berisiko tinggi. Lejar menyemak semula versi dalam transaksinya, jadi keputusan lama yang dicache tidak boleh mengkomit pembayaran yang diubah.

Adakah DPoP menghalang semua ulang tayang?

Tidak. Ia mengurangkan ulang tayang token yang disalin apabila penyerang tidak mempunyai kunci peribadi dan membolehkan pelayan mengesan bukti yang digunakan semula. Ia tidak menghalang pemegang kunci yang berniat jahat daripada mengulangi arahan yang dibenarkan, jadi keidempotennan lejar, pengesahan sekali sahaja, had kadar dan pembatalan peranti tetap diperlukan.