Pembangun Mencadangkan JWT Bertandatangan Sendiri untuk Menggantikan Kunci API Tradisional

Pasukan Komuniti BigGo
Pembangun Mencadangkan JWT Bertandatangan Sendiri untuk Menggantikan Kunci API Tradisional

Seorang pembangun telah mencetuskan perdebatan komuniti dengan mencadangkan JSON Web Tokens (JWTs) bertandatangan sendiri sebagai alternatif kepada sistem pengurusan kunci API tradisional. Cadangan ini bertujuan untuk menghapuskan proses persediaan yang kompleks yang biasanya melibatkan penciptaan akaun, pengesahan e-mel, pengurusan kunci klien dan pelayan yang berasingan, serta pengendalian kelayakan rahsia dengan berhati-hati.

Memudahkan Pengesahan API

Idea teras berpusat pada pembangun yang menjana pasangan kunci kriptografi mereka sendiri dan bukannya bergantung pada penyedia perkhidmatan untuk mengeluarkan kunci API. Menggunakan perpustakaan JavaScript seperti 'jose', pembangun boleh mencipta pasangan kunci awam-peribadi dalam beberapa baris kod sahaja. Pendekatan ini akan membolehkan akses segera kepada API dengan peringkat percuma tanpa geseran penciptaan akaun yang biasa.

Cadangan ini mencadangkan penyimpanan kunci peribadi pada pelayan sambil memasukkan kunci awam terus dalam pengepala JWT. Ini menghapuskan keperluan untuk kunci boleh terbit dan rahsia yang berasingan yang diperlukan oleh banyak perkhidmatan API semasa. Sebaliknya, tindakan istimewa akan dinyatakan sebagai tuntutan dalam muatan JWT, dengan pelayan menentukan tindakan apa yang perlu dibenarkan berdasarkan logiknya sendiri.

JWT (JSON Web Token): Cara padat untuk menghantar maklumat dengan selamat antara pihak sebagai objek JSON, ditandatangani secara digital untuk mengesahkan ketulenan.

Contoh Kod Penjanaan JWT:

import { generateKeyPair, exportJWK } from 'jose'

const keyPair = await generateKeyPair('ES256', {
  extractable: true,
})

const publicKeyJWK = await exportJWK(keyPair.publicKey)
const privateKeyJWK = await exportJWK(keyPair.privateKey)

Kebimbangan Komuniti Mengenai Keselamatan

Beberapa pembangun telah membangkitkan persoalan keselamatan penting mengenai cadangan tersebut. Kebimbangan utama berkisar tentang membenarkan klien menetapkan tuntutan kebenaran mereka sendiri, yang boleh mewujudkan kerentanan keselamatan yang ketara jika dilaksanakan dengan tidak betul.

Penulis menjelaskan bahawa pihak berkuasa penandatanganan JWT masih harus mengawal tuntutan mana yang disertakan, mencadangkan bahawa pelayan boleh menyediakan token pra-tandatangan kepada klien atau menggunakan pendekatan proksi terbalik untuk menambah tuntutan yang dibenarkan. Walau bagaimanapun, sesetengah ahli komuniti masih ragu-ragu tentang kerumitan yang mungkin ditimbulkan.

Paradoks dengan alternatif ialah jika anda cukup bijak untuk mengetahui masalah apa yang diperbaikinya, anda sepatutnya tidak menghadapi masalah tersebut pada mulanya.

Tuntutan: Kenyataan tentang entiti (biasanya, pengguna) yang disertakan dalam JWT, seperti kebenaran atau atribut pengguna.

Cabaran Pelaksanaan dan Alternatif

Pengkritik menunjukkan bahawa banyak langkah persediaan yang dicadangkan untuk dihapuskan masih diperlukan. Pembangun masih perlu menguruskan pasangan kunci, menyimpannya dengan selamat, dan mengelakkan daripada melakukan mereka kepada kawalan sumber. Perbezaan utama ialah menggantikan kunci API dengan kunci peribadi dalam kebanyakan dokumentasi.

Sesetengah ahli komuniti telah mencadangkan PASETO (Platform-Agnostic Security Tokens) sebagai alternatif yang lebih baik kepada standard JOSE yang mendasari JWTs. PASETO direka untuk mengelakkan banyak perangkap keselamatan yang boleh berlaku dengan pelaksanaan JWT, terutamanya sekitar pemilihan algoritma dan pengesahan token.

Perbincangan juga telah menyentuh senario yang lebih maju, seperti kes penggunaan perniagaan-kepada-perniagaan-kepada-pengguna (B2B2C), di mana terbitan kunci hierarki mungkin diperlukan untuk membolehkan pembangun mengeluarkan kunci kepada pengguna akhir mereka sendiri.

PASETO: Format token selamat yang direka untuk menjadi lebih mudah dan selamat daripada JWTs, dengan peluang yang lebih sedikit untuk kesilapan pelaksanaan.

Proses Kunci API Tradisional berbanding JWT Tandatangan Sendiri:

Kunci API Tradisional JWT Tandatangan Sendiri
Lawati laman web dan cipta akaun Jana pasangan kunci secara tempatan
Sahkan alamat e-mel Tiada pengesahan e-mel diperlukan
Cipta projek dan tambah pembayaran Akses API terus dengan peringkat percuma
SDK klien/pelayan berasingan SDK tunggal untuk semua persekitaran
Urus kunci boleh terbit berbanding kunci rahsia Pasangan kunci tunggal dengan pengesahan berasaskan tuntutan

Kesimpulan

Walaupun cadangan JWT bertandatangan sendiri menawarkan pendekatan yang menarik untuk mengurangkan geseran onboarding API, respons komuniti menyerlahkan kerumitan sistem pengesahan. Perdebatan tersebut mencerminkan ketegangan yang lebih luas dalam pembangunan perisian antara kesederhanaan dan keselamatan, dengan pembangun berpengalaman memberi amaran bahawa pengesahan adalah bidang di mana corak yang ditetapkan wujud atas sebab yang baik. Cadangan ini mungkin menemui aplikasi dalam kes penggunaan tertentu, tetapi penggunaan meluas mungkin memerlukan penanganan kebimbangan keselamatan yang dibangkitkan oleh komuniti.

Rujukan: self-signed JWTs