Wawancara Data Engineering: Bagaimana Anda Merancang Koneksi OAuth yang Aman untuk PostgreSQL 18?

Perintah dan konteks

Tim Anda sedang meningkatkan platform analitik multi-tenant ke PostgreSQL 18 dan ingin aplikasi terhubung menggunakan bearer token OAuth 2.0, bukan kata sandi jangka panjang. Jelaskan batas kepercayaan OAuth pada PostgreSQL 18, handshake koneksi, pemetaan peran (role mapping), dan rencana peluncuran (rollout plan). Tunjukkan titik-titik di mana otorisasi dapat meluas secara tidak sengaja atau issuer dapat tertukar.

Hal yang dievaluasi pewawancara

Apakah Anda dapat membedakan antara klien OAuth, server otorisasi, server sumber daya (resource server), dan peran basis data (database role).
Apakah Anda dapat menghubungkan pg_hba.conf, validator, scope, pemetaan (maps), dan pengaturan libpq ke dalam satu alur data.
Apakah Anda mengenali risiko discovery, pencocokan issuer yang presisi, TLS, dan masa berlaku token.
Apakah Anda dapat mengusulkan migrasi yang dapat dibatalkan (reversible) alih-alih sekadar mengatakan "ganti kata sandi dengan token."

Pertanyaan klarifikasi

Apakah pemanggil adalah manusia, layanan backend, atau keduanya? Jenis principal memengaruhi pemilihan klien publik versus rahasia (confidential).
Apakah setiap tenant dipetakan ke peran basis data yang terpisah? Bisakah satu token mewakili beberapa peran?
Apakah penyedia menyediakan dokumen discovery standar dan validator bearer-token?
Bisakah klien lama tetap menggunakan SCRAM, dan berapa lama jendela audit serta rollback-nya?

Jawaban 30 detik

Saya akan memperlakukan PostgreSQL sebagai resource server, libpq/psql sebagai klien OAuth, dan sistem identitas eksternal sebagai server otorisasi; basis data tidak menerbitkan token. Server mengaktifkan oauth di pg_hba.conf dengan issuer, scope, dan validator yang tepat, menggunakan map ketika identitas eksternal harus dipetakan ke peran basis data. Klien menggunakan discovery dan menyajikan bearer token; validator memeriksa tanda tangan, issuer, audience, masa kedaluwarsa, dan scope. Saya akan mempertahankan SCRAM selama peluncuran bertahap tenant-demi-tenant, mengukur alasan penolakan, dan menghapus aturan OAuth untuk melakukan rollback.

Pembahasan mendalam

1. Menentukan batas kepercayaan

PostgreSQL 18 menambahkan metode autentikasi OAuth, bukan server otorisasi. Penyedia mengotorisasi pengguna dan menerbitkan token; PostgreSQL memvalidasi token dan memutuskan apakah suatu koneksi dapat mengambil suatu peran basis data. Memperlakukan basis data sebagai UI login atau menyimpan refresh token di sana akan memperluas tanggung jawabnya secara tidak tepat.

2. Mengonfigurasi aturan server

Tambahkan aturan oauth di pg_hba.conf untuk jaringan dan basis data target, dengan issuer, scope, validator opsional, dan map opsional. Issuer harus cocok karakter demi karakter dengan dokumen discovery. Jika beberapa validator terpasang, pilih salah satu secara eksplisit. Letakkan aturan ini sebelum aturan kata sandi umum agar permintaan tidak jatuh ke metode yang tidak diinginkan.

3. Menangani discovery dan handshake

libpq menggunakan oauth_issuer untuk mengambil metadata discovery dan kemudian memperoleh token sebagaimana diwajibkan oleh server. Issuer pada klien harus sama dengan issuer pada HBA. PostgreSQL mendokumentasikan perbandingan persis ini sebagai perlindungan terhadap serangan mix-up. Jangan pernah menaruh bearer token di log koneksi, argumen proses, atau konfigurasi permanen.

4. Memvalidasi token dan peran

Sebuah validator harus memeriksa tanda tangan, issuer, masa berlaku, audience, dan scope yang diperlukan, kemudian mengembalikan identitas eksternal yang dapat diaudit. Tanpa map, nama pengguna yang divalidasi harus sama persis dengan peran yang diminta. Untuk multi-tenancy, gunakan pemetaan least-privilege yang eksplisit dengan perilaku tolak-secara-default (deny-by-default). delegate_ident_mapping melewati pemetaan standar pg_ident.conf dan hanya boleh digunakan jika validator itu sendiri melakukan otorisasi peran secara lengkap.

5. Meluncurkan dan membatalkan (Roll out dan Roll back)

Verifikasi discovery, TLS, scope, dan perilaku token kedaluwarsa di luar lingkungan produksi. Tambahkan aturan HBA OAuth untuk sekelompok kecil layanan sambil tetap mempertahankan SCRAM. Ukur keberhasilan, kedaluwarsa, ketidakcocokan issuer, dan penolakan pemetaan secara terpisah. Perluas setelah pool koneksi, pekerjaan batch, dan skrip operasional dapat me-refresh token. Lakukan rollback dengan menghapus aturan OAuth atau memulihkan SCRAM sambil mempertahankan kredensial lama hingga setiap pool selesai beralih.

Contoh jawaban berkualitas tinggi

Saya akan memetakan empat aktor: layanan sebagai klien, platform identitas sebagai server otorisasi, PostgreSQL sebagai resource server, dan peran basis data sebagai target otorisasi lokal. Metode HBA oauth menentukan issuer, scope, dan validator serta memetakan identitas token ke peran tenant. Saya akan menghindari delegate_ident_mapping kecuali validator itu sendiri membuktikan otorisasi peran. Klien akan menggunakan discovery oauth_issuer, menerapkan TLS, dan menjaga agar token tidak masuk ke log. Selama peluncuran bertahap tenant-demi-tenant, SCRAM tetap tersedia, sementara dasbor memisahkan kegagalan issuer, scope, kedaluwarsa, dan pemetaan. Menghapus aturan OAuth merupakan bentuk rollback langsung. Pendekatan ini memanfaatkan kemampuan bawaan PostgreSQL 18 sembari tetap memisahkan penerbitan token, otorisasi basis data, dan kendali migrasi.

Kesalahan umum

Mengklaim bahwa PostgreSQL menerbitkan token OAuth, mencampuradukkan resource server dan server otorisasi.
Hanya memeriksa tanda tangan JWT dan melewatkan pemeriksaan issuer, audience, masa kedaluwarsa, atau scope.
Menganggap bahwa issuer pada domain yang sama sudah cukup dan mengabaikan pencocokan discovery yang presisi.
Mengaktifkan delegate_ident_mapping tanpa menjelaskan otorisasi peran di sisi validator.
Menulis bearer token ke log koneksi, trace, atau variabel lingkungan jangka panjang.
Menghapus SCRAM dalam satu langkah sekaligus sehingga membuat pool dan batch job tanpa jalur rollback.

Pertanyaan lanjutan dan jawaban

Mengapa issuer harus cocok secara persis?

Klien membuat URL discovery dari issuer dan membandingkan issuer yang dikembalikan dengan konfigurasinya. Perbedaan huruf besar/kecil, pemformatan, dan path dapat menggagalkan koneksi; perbandingan yang ketat juga mencegah klien dialihkan ke server otorisasi yang tidak diinginkan.

Bagaimana peran dipilih tanpa pemetaan?

Nama pengguna yang dikembalikan oleh validator harus sama persis dengan peran yang diminta oleh koneksi. Penerapan multi-tenant biasanya memerlukan pemetaan eksplisit dengan perilaku deny-by-default agar suatu identitas tidak secara otomatis masuk ke dalam peran dengan hak istimewa (privileged role).

Bagaimana Anda menjaga ketersediaan saat OAuth gagal?

Pertahankan kredensial SCRAM berumur pendek untuk rollback dan migrasikan pool secara bertahap. Pantau kegagalan berdasarkan jenisnya, lalu hapus aturan HBA OAuth dan pulihkan aturan sebelumnya jika terjadi masalah pada discovery, scope, atau perilaku validator.