Jwt-auth: [pertanyaan] Kasus penggunaan API tanpa kepala

Dibuat pada 12 Des 2019 · 3Komentar · Sumber: WP-API/jwt-auth

Arsitektur aliran auth di plugin ini sangat bagus; Saya memahami masalah keamanan. Meskipun mungkin menonaktifkan kasus penggunaan utama dari fitur tersebut: Wordpress sebagai CMS tanpa kepala.

Menonaktifkan autentikasi CMS tanpa kepala

CMS tanpa kepala akan mengharuskan pengguna untuk masuk melalui username dan password . Setelah pengguna memiliki JWT, mereka dapat mengirim permintaan yang diautentikasi ke sumber daya yang dilindungi, dalam lingkungan CMS tanpa kepala akan menjadi penghalang dan berlawanan dengan intuisi untuk meminta pengguna membuat token API.

Keamanan harus diimplementasikan melalui hak istimewa RBAC, peran dan tanggung jawab pengguna yang menentukan apa yang dilindungi dalam API. Masalah keamanan dapat dikurangi melalui standar RBAC yang sangat ketat. Sudah Wordpress memiliki kerangka peran dan tanggung jawab yang besar.

Untuk mengatasi masalah keamanan yang sebenarnya:

Token berumur panjang? Jadikan mereka token berumur pendek.
Kekhawatiran bahwa token berumur panjang dapat dicuri? Begitu juga token API, argumen nol.
Praktik terbaik JWT menentukan tokens berumur pendek dan refresh_tokens berumur pendek (token penyegaran dapat dibatalkan) Jadi ini lebih aman daripada membagikan token API hidup tak terbatas yang dapat hilang.

Bukankah ini hanya OAuth2 ?

Pendekatan ini pada dasarnya adalah skenario pemberian token oAuth2 "personal access" . Jadi saya akan mempertanyakan manfaat dari pendekatan server auth token kustom seperti ini di atas implementasi standar oAuth2 yang tepat? Jika keamanan menjadi perhatian utama di sini, maka pendekatan ini benar-benar menghadirkan risiko keamanan? misalnya implementasi oAuth2 yang diuji pertempuran seperti php-league-oatuh-2

Saya melihat satu-satunya kasus penggunaan yang layak untuk aliran autentikasi saat ini application-to-application otentikasi? oAuth2 menjabarkan beberapa metode aliran auth untuk memberikan token. Salah satunya adalah apa yang digunakan pendekatan ini "personal access" dan yang lainnya adalah apa yang saya gambarkan token "password access" . Implementasi oAuth2 penuh akan memungkinkan kedua skenario ini dan lainnya...

Lebih jauh

Kami percaya penyerapan WP-API dan dengan demikian modernisasi ekosistem Wordpress secara umum akan sangat ditingkatkan jika hal-hal seperti autentikasi API stateless mudah diakses oleh pengembang.

Ini hanya renungan dan ingin berdiskusi dan berkontribusi!

Kerja bagus!

tim tanpa kepala wp

Sumber

andrewmclagan

👍3 🚀1 ❤1

Komentar yang paling membantu

Saya telah membangun aplikasi asli (atau mencoba) sejak sebelum REST API membuatnya menjadi inti. (yaitu: tahun)

Awalnya, satu-satunya cara aplikasi saya mengautentikasi dan mengunggah/membuat konten adalah dengan menggunakan plugin 'OAuth1.0a' yang dimulai oleh tim API.

Saya sekarang memiliki banyak hal yang berfungsi untuk OAuth2.0 (sekali lagi, fitur lain yang membutuhkan plugin tambahan diinstal. Tidak tahu apakah ini akan menjadi inti)

Dan sekarang kami memiliki JWT yang menghadirkan masalah baru dalam cara menghubungkan aplikasi saya. Secara alami nama pengguna/kata sandi akan berfungsi lebih baik, memberikan token. (Untungnya versi 'WP-API' dari JWT mendukung penyegaran token. Plugin JWT lain yang banyak digunakan tidak)

Saya tidak percaya banyaknya peluang yang hilang (dan waktu) yang berlalu, dengan tidak memiliki implementasi 'tanpa kepala'/seluler yang solid untuk otentikasi 'di luar kotak' (dalam inti).

Aplikasi seluler saya memerlukan pluginnya sendiri untuk melakukan tugasnya dan mendukung banyak hal terkait admin dan peningkatan rute. blok khusus dll. Saya lebih suka tidak membuat pengguna/pelanggan aplikasi saya harus mengunduh dan menginstal plugin 'belum selesai' lainnya.

Saya hanya berharap ada solusi yang solid (dan 'resmi').

kosso pada 17 Des 2019

👍3

Semua 3 komentar

Saya telah membangun aplikasi asli (atau mencoba) sejak sebelum REST API membuatnya menjadi inti. (yaitu: tahun)

Awalnya, satu-satunya cara aplikasi saya mengautentikasi dan mengunggah/membuat konten adalah dengan menggunakan plugin 'OAuth1.0a' yang dimulai oleh tim API.

Saya sekarang memiliki banyak hal yang berfungsi untuk OAuth2.0 (sekali lagi, fitur lain yang membutuhkan plugin tambahan diinstal. Tidak tahu apakah ini akan menjadi inti)

Saya tidak percaya banyaknya peluang yang hilang (dan waktu) yang berlalu, dengan tidak memiliki implementasi 'tanpa kepala'/seluler yang solid untuk otentikasi 'di luar kotak' (dalam inti).

Saya hanya berharap ada solusi yang solid (dan 'resmi').

kosso pada 17 Des 2019

👍3

Saya sangat setuju. Wordpress diposisikan untuk menjadi pemimpin di arena cms tanpa kepala. Tampaknya tim inti membuat terobosan untuk itu, tetapi mungkin hanya untuk melayani kasus penggunaan khusus untuk wordpress.com? Tidak yakin.

Kami sedang mengembangkan klien isomorfik untuk tujuan ini. Seiring dengan kait dan penyedia reaksi. https://github.com/wp-headless/fetch. Mungkin kita harus menulis plugin auth JWT kita sendiri. Pikiran saya tentang seperti apa seharusnya:

Ikuti spesifikasi oAuth2 (mengapa membuat aliran auth khusus?)
Memiliki beberapa metode pemberian token: password , machine-to-machine , api-key dll.
bergantung pada paket terkemuka yang teruji dengan baik.

andrewmclagan pada 18 Des 2019

Di sini saya terjebak dengan mencoba menerapkan sistem pendaftaran/otentikasi pengguna melalui WP REST API, hanya untuk mengetahui tim WP ~~menemukan kembali roda~~ menciptakan roda baru.