Jwt-auth: UX Aliran Token yang Diperbarui

Terima kasih telah meluangkan waktu untuk menulis semua ini. Jika Anda merasa sesuatu yang berikut ini kasar, itu tidak dimaksudkan, saya hanya memberikan pendapat saya dan bukan satu-satunya, kemungkinan ada campuran dari mereka dan debat baik-baik saja.

Saya khawatir bahwa perubahan ini membuat fungsionalitas plugin ini tidak dapat diakses oleh sebagian besar pengguna non-teknis, yang berharap dapat masuk menggunakan nama pengguna dan kata sandi mereka.

Saya mengerti apa yang Anda coba katakan di sini tetapi pada saat yang sama apa yang Anda sarankan adalah mengharuskan pengguna untuk masuk ke WordPress dan membuat pasangan kunci entah bagaimana sulit bagi pengguna non-teknis yang ingin membuat token melalui REST API secara terprogram. Saya berpendapat bahwa ini sama sekali bukan pengguna _non-teknis_.

Selain itu, di setiap sistem yang aman akan ada hambatan masuk yang harus diatasi pengguna untuk menggunakannya. Google tidak mengizinkan Anda membuat koneksi JWT atau OAuth dengan menggunakan nama pengguna dan sandi Anda dalam permintaan API. Itu tidak aman. Harus ada cara untuk memastikan bahwa token atau koneksi auth dilampirkan ke pengguna dengan cara yang dapat dibatalkan.

Ini tidak intuitif
Sistem lain yang ingin menggunakan metode ini untuk berintegrasi dengan WordPress perlu memiliki penjelasan/tutorial tentang cara menyiapkan pasangan kunci untuk memulai.

Untuk memiliki model aman yang mendukung pemisahan akses dan otentikasi, Anda harus memiliki pagar pembatas yang menjaga token berumur panjang agar tidak menjadi titik akses tak terbatas. Dengan penambahan token penyegaran, pengguna jahat dapat membuat akses dan token penyegaran dengan kombinasi user:pass yang tidak akan pernah dapat kami batalkan jika tidak ada pasangan kunci, atau yang setara, untuk membatalkan token.

Memberitahu pengguna untuk masuk ke WordPress dan membuka Profil mereka untuk menghasilkan pasangan kunci adalah harga kecil yang harus dibayar untuk keamanan. Selain itu, petunjuknya sangat sederhana.

Sulit digunakan antar perangkat
Jika saya berharap menggunakan kunci ini untuk aplikasi di ponsel saya, tidak ada cara mudah untuk mendapatkannya. Saya tidak ingin mengetikkan rangkaian huruf, angka, dan karakter khusus yang panjang di ponsel saya – kemungkinan besar saya akan membuat kesalahan transkripsi. Kami dapat menghapus tingkat kesulitan transkripsi dengan membuat kode QR yang dapat dipindai orang, tetapi kemudian kami kembali ke masalah di atas – orang mungkin perlu mengunduh aplikasi kode QR, atau pengembang pihak ketiga perlu membuat kode QR parsing perpustakaan ke dalam aplikasi mereka untuk bekerja dengan kami.

Tolong jelaskan aplikasi ini yang terus Anda rujuk, mengapa aplikasi ini menangani semua auth dan login untuk Anda? Itu tidak aman. Anda akan memberikan aplikasi ini semua akses dan autentikasi yang diperlukan untuk melakukan apa pun yang diinginkan ke situs web Anda. Anda harus mempertimbangkan bahwa mungkin arsitektur aplikasi salah dan alur autentikasi ini untuk mencegah hal yang persis seperti yang Anda gambarkan.

Apa yang Anda jelaskan kepada saya adalah aplikasi yang menyimpan nama pengguna dan kata sandi plaintext Anda sehingga dapat masuk ke WordPress melalui REST API untuk menghasilkan token yang digunakan untuk mengakses sumber daya, tetapi juga sepenuhnya mampu membuang database Anda melalui yang sama sarana otentikasi dan akses. Saya tidak mengerti mengapa kami ingin mendukung apa pun yang dekat dengan kasus penggunaan ini seperti yang Anda jelaskan.

Itu tidak mendorong kebersihan keamanan yang baik
Idealnya, pengguna akan menjaga kunci mereka dengan hati-hati untuk memastikan bahwa tidak ada yang ketinggalan zaman, tanpa kompromi, dll. Sayangnya, kami tidak dapat mengandalkan ini, dan kunci yang disusupi bahkan lebih berbahaya daripada token yang disusupi. Kemungkinan juga rata-rata pengguna akan membuat kunci baru setiap kali mereka membutuhkannya, daripada menyimpan rahasia di tempat yang aman.

Pertama, pasangan kunci tidak dilampirkan pada tanggal kedaluwarsa dan satu-satunya hal yang dapat mereka lakukan saat ini adalah membuat token, jadi saya gagal melihat bagaimana mereka _lebih berbahaya_ daripada token yang dikompromikan karena merekalah yang membatalkan token itu. Kedua, pengguna tidak melakukan apa pun dengan hati-hati, dan kita tidak boleh mengharapkan mereka memahami implikasi keamanan dari tindakan mereka. Kita harus berasumsi bahwa mereka sangat tidak kompeten dan mungkin cukup malas untuk tidak pernah membersihkan diri mereka sendiri. Namun, membuat pasangan kunci tambahan bukanlah masalah keamanan. Masalah keamanan akan memberikan nama pengguna dan kata sandi plaintext Anda ke aplikasi asing.

Selain itu – Saya khawatir tentang menambahkan metode tambahan untuk mencabut sesi – WordPress sudah memiliki tombol "Log Out Everywhere Else" di halaman profil – sebagai pengguna, saya berharap itu akan mengeluarkan saya dari aplikasi apa pun juga ( atau setidaknya beri tahu saya apakah saya ingin melakukan itu?)

Kami dapat meminta pengguna untuk menghapus pasangan kunci mereka, tetapi saya tidak akan pernah mengharapkan logout untuk menghancurkan token saya. Itu bukan perilaku normal atau yang diharapkan dari sistem seperti ini dan kemungkinan akan menciptakan kekacauan dan banyak permintaan dukungan.

Itu tidak memberikan keamanan tambahan
Jika saya, sebagai penyerang, sudah memiliki nama pengguna dan kata sandi Anda, tidak ada yang tidak bisa saya lakukan seperti Anda (dengan asumsi tidak ada 2FA di tempat).

Saya sangat tidak setuju. Pendekatan ini memberikan keamanan tambahan untuk mengakses sumber daya REST Anda dan jika itu tidak jelas maka kami memerlukan lebih banyak dokumentasi untuk membuatnya jelas. Anda berargumen bahwa jika seseorang sudah memiliki kredensial Anda maka Anda kacau, tetapi Anda juga menyarankan agar kami menggunakannya untuk memberikan akses ke REST API. Jika itu cara Anda ingin mengakses REST maka gunakan Basic Auth. Karena itulah tepatnya yang akan kami terapkan jika kami menggunakan user:pass untuk membuat token.

Ini mengarah pada fakta bahwa, jika saya sebagai pengembang aplikasi pemula ingin membuat hidup pengguna saya lebih mudah, saya mungkin mencoba sesuatu yang tidak disarankan seperti menggunakan browser tanpa kepala untuk masuk ke akun pengguna, membuat token, membaca detailnya, lalu tarik mereka kembali ke aplikasi saya.

Di sinilah kita ingin membuat alur autentikasi yang memungkinkan untuk memberikan pasangan kunci pada aplikasi melalui penggunaan panggilan balik. Saya yakin hal seperti ini telah diterapkan di plugin kata sandi aplikasi.

Saya 100% terbuka untuk membuat alur autentikasi untuk aplikasi yang ketika Anda membukanya, Anda diminta untuk masuk ke WordPress, dengan tambahan apa pun seperti 2faktor ditambahkan, yang akan menghasilkan pasangan kunci untuk Anda dan kemudian menggunakan semacam panggilan balik berikan aplikasi pasangan kunci. Maka pengembang aplikasi tidak perlu membuat banyak solusi buruk dan aplikasi tidak menyimpan user:pass .

Apa yang bisa dilakukan sebagai gantinya?
Kunci saat ini memiliki tujuan penting – digunakan untuk memungkinkan pencabutan token, meskipun token berpotensi berumur panjang. Namun, kita tidak perlu pasangan kunci untuk melakukan ini.

Benar, Anda bisa menggunakan banyak pendekatan berbeda.

Mengambil inspirasi dari entri session_tokens WordPress di usermeta – kumpulan kunci pencabutan khusus JWT yang tersimpan akan memungkinkan fungsionalitas yang sama, dan akan membuatnya sepele untuk mengimplementasikan fungsionalitas "Log Out Everywhere Else" – hapus saja entri itu dari tabel.

Ini tidak akan pernah menjadi pengganti implementasi saat ini yang harus ditambahkan. Saya, sebagai pengembang perangkat lunak perusahaan, tidak akan pernah menggunakan metode ini. Jadi meskipun ini adalah pendekatan yang valid, ia tidak memiliki kemampuan untuk mengharapkan token valid selama tidak kedaluwarsa atau token tidak dicabut. Dalam skenario Anda begitu Anda keluar, token tidak valid. Ini akan menjadi kekurangan IMO dalam aliran autentikasi yang akan menyebabkan masalah yang tak terhitung jumlahnya dengan kemampuan aplikasi saya untuk mendapatkan akses sumber daya karena sekarang digabungkan erat dengan pengguna yang masuk.

Bagaimana dengan 2FA?
Saya bertanya-tanya apakah mungkin untuk mengizinkan pengait yang dapat digunakan plugin 2FA untuk memberi tahu klien "silakan coba lagi, berikan token 2FA" jika diperlukan, tetapi tidak disediakan. Selain itu, kait lain (atau mungkin yang sama?) dapat digunakan untuk mengizinkan plugin 2FA memverifikasi bahwa kode yang diberikan sudah benar? Sistem JWT tidak akan membuat asumsi tentang bagaimana 2FA diimplementasikan – yang akan diserahkan ke plugin lain – kami hanya menyediakan kait untuk membuat hal seperti itu menjadi mungkin.

Ini akan IMO menambahkan lapisan kompleksitas yang tidak perlu yang berpotensi membuat banyak permintaan dukungan.

Terima kasih telah membaca sejauh ini – semua hal di atas adalah IMHO, tapi saya harap kami dapat menyederhanakan proses ini sedikit bagi pengguna untuk membuatnya bekerja dengan sangat baik di luar kotak untuk semua orang.

Saya yakin saya telah melewatkan setidaknya sesuatu, jadi saya senang mendengar umpan balik dari orang-orang tentang ini!

Pos epik. Terima kasih telah meluangkan waktu untuk menuliskan semua ini. Anda benar-benar memberikan ini banyak pemikiran. Saya ingin mengatakan bahwa saya tidak mencoba untuk menembak jatuh apa pun. Hanya saja jika kita akan mengizinkan token dibuat dengan kombinasi user:pass maka cara kita melakukannya harus sangat sangat aman dan tidak memiliki potensi aplikasi untuk menyimpan kredensial login Anda.

Titik memisahkan akses dan otentikasi adalah tujuan dan tidak boleh dianggap enteng. Kami sedang membangun otentikasi REST potensial untuk 1/3 dari internet. Jadi sampai kami memiliki jalur ke depan, saya menghapus kemampuan untuk membuat token dengan kredensial pengguna. Bukan berarti kita tidak bisa menambahkannya kembali, hanya saja perlu banyak diskusi sebelum kita melakukannya.

Hai! Dari apa yang saya pahami, titik sakit utama tentang percakapan di sini adalah kegunaan. Memang membuat pengguna pergi ke situs untuk masuk dan membuat pasangan kunci akan menjadi sumber masalah, atau ketidaknyamanan, bagi sebagian pengguna.

Pengembang kemungkinan akan mencoba menemukan cara tidak aman untuk menghindarinya dengan cara yang sama saat ini mereka menghapus fungsionalitas yang memerlukan kata sandi yang kuat demi penggunanya.

Meskipun saya memahami aspek keamanan dalam keputusan tersebut, dan agak setuju. Tetapi kita perlu menemukan cara yang dapat bekerja untuk keduanya.

Tampaknya apa yang Anda katakan di sini @valendesigns bisa menjadi solusi yang memungkinkan:

Saya 100% terbuka untuk membuat alur autentikasi untuk aplikasi yang ketika Anda membukanya, Anda diminta untuk masuk ke WordPress, dengan tambahan apa pun seperti 2faktor ditambahkan, yang akan menghasilkan pasangan kunci untuk Anda dan kemudian menggunakan semacam panggilan balik berikan aplikasi pasangan kunci. Maka pengembang aplikasi tidak perlu membuat banyak solusi buruk dan aplikasi tidak menyimpan user:pass mereka.

Dari apa yang saya pahami, pada dasarnya kami akan menjaga aliran saat ini, yang lebih aman karena kami tidak perlu memberikan kata sandi kami ke aplikasi alih-alih hanya memberikan pasangan kunci untuk menghasilkan token, tetapi itu mungkin menjadi rintangan bagi beberapa orang .

Menjaga aliran lain ini di mana kami tidak perlu memberikan kata sandi kami ke aplikasi asing. Sebagai gantinya, minta mereka untuk masuk ke WordPress dan membuat pasangan kunci.

Saya ingin informasi lebih lanjut tentang bagian ini:

Kami dapat meminta pengguna untuk menghapus pasangan kunci mereka, tetapi saya tidak akan pernah mengharapkan logout untuk menghancurkan token saya. Itu bukan perilaku normal atau yang diharapkan dari sistem seperti ini dan kemungkinan akan menciptakan kekacauan dan banyak permintaan dukungan.

Tampaknya jika saya masuk site.com melalui browser dan aplikasi, jika saya mengklik "Log Out Everywhere Else" di browser, saya juga akan logout di aplikasi, bukan?! Saya dapat melihat aplikasi di mana ini akan menjadi asumsi. Harapannya Anda akan logout di mana-mana.

Hal yang sama perlu terjadi ketika akun dihapus.

Saya harus setuju dengan apa yang dikatakan tentang UX pasangan kunci yang sangat tidak ramah pengguna.

Sangat sulit untuk membangun aplikasi seluler asli yang dapat menggunakan metode Auth ini.

• Saya telah membuat plugin khusus beberapa waktu lalu untuk plugin OAuth1a (lama) yang menampilkan kode QR terenkripsi (dengan kata sandi pendek yang dapat diatur) di halaman admin Aplikasi (ketika nama aplikasi dan url panggilan balik cocok dengan aplikasi saya), yang kemudian meneruskan info aplikasi klien ke aplikasi seluler, untuk kemudian mengizinkan pengguna mengautentikasi.

Memang (pun intended), JWT jauh lebih mudah daripada OAuth1a ;)

Karena pengguna harus masuk ke Wordpress (semoga melalui https) di tempat pertama, menggunakan nama pengguna dan kata sandi, saya benar-benar tidak melihat apa masalah keamanan memiliki pasangan nama pengguna/kata sandi yang bisa mendapatkan token akses ? Semuanya dikirim melalui 'kawat' yang sama di penghujung hari? Pasti?

Menerapkan pasangan kunci aplikasi yang saat ini diterapkan membuat metode autentikasi ini benar-benar mustahil (di dunia nyata) untuk digunakan pada aplikasi seluler.

Tidak ada cara yang masuk akal untuk mendapatkan aplikasi seluler untuk memasukkannya.

Saya sudah mencoba OAuth1a, OAuth2 dan sekarang dua plugin JWT untuk mengimplementasikan aplikasi asli saya dengan akses dan semuanya gagal 'out-of-the-box' , tanpa beberapa peretasan untuk mencoba dan membuat sesuatu berfungsi untuk pengguna. Hal ini seharusnya menjadi lebih mudah, tentunya?

Plugin JWT pihak ketiga di luar sana (dengan 10.000+ pemasangan) mendukung pengguna/pass, dan berfungsi dengan baik untuk aplikasi seluler asli yang saya buat. Tetapi gagal karena kurangnya token penyegaran melalui plugin, memaksa pengguna untuk 'masuk' lagi. (ini juga memerlukan pengeditan manual wp-config)

Plugin 'soon-to-be-official' (saya harap!) ini gagal karena kurangnya keramahan pengguna seluler dan tampaknya mengabaikan jenis aplikasi apa yang secara realistis dapat dikembangkan untuk itu. Dan itu tampaknya sangat picik.

Ada alasan mengapa ada kekurangan aplikasi seluler asli untuk memposting ke situs wp.org. Dan ini.

Tolong, tolong tolong bisakah kita mendapatkan beberapa gerakan tentang ini? (Saya telah mengerjakan aplikasi asli selama bertahun-tahun sekarang, menunggu cara yang 'tepat' untuk mengautentikasi pengguna, sejak pengenalan REST API)

:)

Aliran token UX gila dan tidak praktis untuk penggunaan dunia nyata, pengguna harus dapat masuk dengan nama pengguna dan kata sandi pada sistem meminta pasangan kunci API tidak masuk akal, Anda tidak menggunakan abstraksi di sini, Anda seharusnya untuk melindungi pengguna dari teknis penggunaan aplikasi Anda, bagaimana perasaan Anda bahwa untuk masuk ke Facebook di ponsel Anda, Anda harus masuk ke portal admin di facebook dan membuat pasangan kunci API dan kemudian menggunakan pasangan kunci API untuk masuk, kami tidak mengembangkan untuk pengembang, kami mengembangkan untuk pelanggan yang tidak tahu apa aspek teknis dari layanan Anda, langsung mencopot pemasangan. Saya benar-benar tidak melihat bagaimana plugin ini berguna untuk otentikasi.

Masalah dengan login pengguna> aliran token ini secara serius menghambat pengembangan begitu banyak aplikasi yang dapat menggunakan JWT.

Bulan demi bulan terus berlalu dan itu sama sekali tidak ditangani.

Seperti yang saya katakan di atas, fakta bahwa pengguna menggunakan pasangan nama pengguna/kata sandi untuk benar-benar Masuk ke Admin membuat argumen apa pun untuk menggunakan tidak menggunakan pasangan nama pengguna/kata sandi untuk mendapatkan token tampak agak tidak valid? Pasti?

Hanya untuk memperbarui utas ini – sepertinya proyek ini digantikan oleh satu untuk mengimplementasikan aliran OAuth penuh di inti WP. Ini harus mengatasi kelemahan dari pendekatan yang dibahas di sini sambil mempertahankan semua kekuatan.

Jika Anda ingin terlibat dengan itu, silakan masuk ke #core-resttapi di Slack .