Temu Duga Kejuruteraan Data: Bagaimanakah Anda Mereka Bentuk Sambungan OAuth yang Selamat untuk PostgreSQL 18?

Arahan dan konteks

Pasukan anda sedang menaik taraf platform analitik berbilang penyewa (multi-tenant) kepada PostgreSQL 18 dan mahu aplikasi menyambung menggunakan token pembawa (bearer tokens) OAuth 2.0 berbanding kata laluan jangka panjang. Terangkan sempadan OAuth PostgreSQL 18, jabat tangan (handshake) sambungan, pemetaan peranan, dan pelan pelancaran. Nyatakan bahagian di mana kebenaran (authorization) boleh diperluaskan secara tidak sengaja atau pengeluar (issuer) boleh dikelirukan.

Perkara yang dinilai oleh penemu duga

Sama ada anda membezakan antara klien OAuth, pelayan kebenaran, pelayan sumber, dan peranan pangkalan data.
Sama ada anda boleh menghubungkan pg_hba.conf, pengesah, skop, pemetaan, dan tetapan libpq ke dalam satu aliran data.
Sama ada anda menyedari risiko penemuan (discovery), pemadanan tepat pengeluar, TLS, dan jangka hayat token.
Sama ada anda boleh mencadangkan migrasi yang boleh diterbalikkan berbanding sekadar menyatakan "gantikan kata laluan dengan token."

Soalan penjelasan

Adakah pemanggil terdiri daripada manusia, perkhidmatan bahagian belakang (backend), atau kedua-duanya? Prinsipal mempengaruhi sama ada klien adalah jenis awam atau sulit.
Adakah setiap penyewa dipetakan kepada peranan pangkalan data yang berasingan? Bolehkah satu token mewakili beberapa peranan?
Adakah penyedia mendedahkan dokumen penemuan standard dan pengesah token pembawa?
Bolehkah klien legasi terus menggunakan SCRAM, dan berapa lamakah tempoh audit serta pengunduran (rollback)?

Jawapan 30 saat

Saya akan menganggap PostgreSQL sebagai pelayan sumber, libpq/psql sebagai klien OAuth, dan sistem identiti luaran sebagai pelayan kebenaran; pangkalan data tidak mengeluarkan token. Pelayan mendayakan oauth dalam pg_hba.conf dengan pengeluar, skop, dan pengesah yang tepat, menggunakan map apabila identiti luaran mesti dipetakan kepada peranan pangkalan data. Klien menggunakan penemuan dan mengemukakan token pembawa; pengesah memeriksa tandatangan, pengeluar, khalayak (audience), tarikh luput, dan skop. Saya akan mengekalkan SCRAM semasa pelancaran secara berperingkat mengikut penyewa, mengukur sebab penolakan, dan membuang peraturan OAuth untuk melakukan pengunduran.

Penyelaman mendalam

1. Tentukan sempadan kepercayaan

PostgreSQL 18 menambah kaedah pengesahan OAuth, bukannya pelayan kebenaran. Penyedia membenarkan pengguna dan mengeluarkan token; PostgreSQL mengesahkan token dan menentukan sama ada sesuatu sambungan boleh mengambil peranan pangkalan data. Menganggap pangkalan data sebagai UI log masuk atau menyimpan token penyegaran di dalamnya akan meluaskan tanggungjawabnya secara tidak wajar.

2. Konfigurasikan peraturan pelayan

Tambah peraturan oauth dalam pg_hba.conf untuk rangkaian dan pangkalan data sasaran, bersama-sama issuer, scope, validator pilihan, dan map pilihan. Pengeluar mesti sepadan dengan dokumen penemuan aksara demi aksara. Sekiranya beberapa pengesah dipasang, pilih satu secara eksplisit. Letakkan peraturan ini sebelum peraturan kata laluan yang luas supaya permintaan tidak terlepas kepada kaedah yang tidak diingini.

3. Kendalikan penemuan dan jabat tangan

libpq menggunakan oauth_issuer untuk mengambil metadata penemuan dan kemudian mendapatkan token seperti yang diperlukan oleh pelayan. Pengeluar klien mestilah sama dengan pengeluar HBA. PostgreSQL mendokumentasikan perbandingan tepat ini sebagai pertahanan terhadap serangan kekeliruan (mix-up attacks). Jangan sekali-kali meletakkan token pembawa dalam log sambungan, argumen proses, atau konfigurasi yang tahan lama.

4. Sahkan token dan peranan

Pengesah harus memeriksa tandatangan, pengeluar, jangka hayat, khalayak, dan skop yang diperlukan, kemudian mengembalikan identiti luaran yang boleh diaudit. Tanpa map, nama pengguna yang disahkan mestilah sama dengan peranan yang diminta. Untuk persekitaran berbilang penyewa, gunakan pemetaan keistimewaan paling sedikit yang eksplisit dengan tingkah laku nafi-secara-lalai (deny-by-default). delegate_ident_mapping memintas pemetaan standard pg_ident.conf dan hanya boleh digunakan apabila pengesah itu sendiri melaksanakan kebenaran peranan yang lengkap.

5. Lancarkan dan undurkan (Roll out dan roll back)

Sahkan penemuan, TLS, skop, dan tingkah laku token luput di luar persekitaran pengeluaran. Tambah peraturan HBA OAuth untuk kumpulan perkhidmatan yang kecil sambil mengekalkan SCRAM. Ukur kejayaan, tamat tempoh, ketidakpadanan pengeluar, dan penolakan pemetaan secara berasingan. Luaskan pelaksanaan selepas kolam sambungan, kerja kelompok, dan skrip operasi berupaya menyegarkan token. Lakukan pengunduran dengan membuang peraturan OAuth atau memulihkan SCRAM sambil mengekalkan kelayakan lama sehingga setiap kolam telah bertukar.

Contoh jawapan berkualiti tinggi

Saya akan menggariskan empat entiti: perkhidmatan ialah klien, platform identiti ialah pelayan kebenaran, PostgreSQL ialah pelayan sumber, dan peranan pangkalan data ialah sasaran kebenaran tempatan. Kaedah HBA oauth menamakan pengeluar, skop, dan pengesah serta memetakan identiti token kepada peranan penyewa. Saya akan mengelakkan delegate_ident_mapping melainkan pengesah itu sendiri membuktikan kebenaran peranan. Klien akan menggunakan penemuan oauth_issuer, menguatkuasakan TLS, dan mengelakkan token daripada dicatat dalam log. Semasa pelancaran mengikut penyewa, SCRAM kekal tersedia, manakala papan pemuka mengasingkan kegagalan pengeluar, skop, tamat tempoh, dan pemetaan. Membuang peraturan OAuth merupakan langkah pengunduran serta-merta. Ini memanfaatkan keupayaan natif PostgreSQL 18 sambil memastikan pengeluaran token, kebenaran pangkalan data, dan kawalan migrasi kekal berasingan.

Kesilapan lazim

Mendakwa bahawa PostgreSQL mengeluarkan token OAuth, sekali gus mengelirukan antara pelayan sumber dan pelayan kebenaran.
Hanya memeriksa tandatangan JWT dan melangkau pemeriksaan pengeluar, khalayak, tarikh luput, atau skop.
Menganggap bahawa pengeluar pada domain yang sama sudah memadai dan mengabaikan pemadanan penemuan yang tepat.
Mendayakan delegate_ident_mapping tanpa menerangkan kebenaran peranan di pihak pengesah.
Menulis token pembawa ke dalam log sambungan, surihan (traces), atau pemboleh ubah persekitaran jangka panjang.
Membuang SCRAM dalam satu langkah dan menyebabkan kolam serta kerja kelompok ketiadaan laluan pengunduran.

Soalan susulan dan jawapan

Mengapakah pengeluar mesti sepadan secara tepat?

Klien membina URL penemuan daripada pengeluar dan membandingkan pengeluar yang dikembalikan dengan konfigurasinya. Perubahan huruf besar/kecil, pemformatan, dan laluan boleh menggagalkan sambungan; perbandingan yang ketat juga menghalang klien daripada dialihkan ke pelayan kebenaran yang tidak diingini.

Bagaimanakah peranan dipilih tanpa pemetaan?

Nama pengguna yang dikembalikan oleh pengesah mestilah sama tepat dengan peranan yang diminta oleh sambungan. Pelaksanaan berbilang penyewa biasanya memerlukan pemetaan eksplisit dengan tingkah laku deny-by-default supaya sesuatu identiti tidak diberikan peranan istimewa (privileged role) secara automatik.

Bagaimanakah anda mengekalkan ketersediaan apabila OAuth gagal?

Simpan kelayakan pengunduran SCRAM jangka pendek dan lakukan migrasi kolam secara beransur-ansur. Pantau kegagalan mengikut jenis, kemudian buang peraturan HBA OAuth dan pulihkan peraturan sebelumnya sekiranya penemuan, skop, atau tingkah laku pengesah mengalami masalah.