Pengesahan dan Keizinan - cara yang betul!

Bayangkan anda sedang membina web atau apl mudah alih yang perlu mengesahkan pengguna — mungkin untuk platform media sosial, tapak e-dagang atau malah papan pemuka yang ringkas. Pada satu ketika, anda akan bertanya kepada diri sendiri, "Bagaimanakah cara untuk memastikan pengguna saya log masuk dengan selamat?"

Di situlah pengesahan dimainkan. Tetapi dengan begitu banyak kaedah berbeza untuk dipilih — seperti pengurusan sesi, token pengesahan dan JWT (Token Web JSON) yang semakin popular — mungkin tidak begitu jelas untuk mengetahui yang mana satu sesuai untuk apl anda. Jadi bagaimana anda membuat keputusan?

Jika anda telah banyak mendengar tentang JWT dan tertanya-tanya sama ada ia berbaloi dengan gembar-gembur, anda berada di tempat yang betul. Dalam catatan blog ini, kami akan memecahkan apa itu JWT, cara ia berfungsi dan cara ia bertindan berbanding kaedah pengesahan biasa yang lain dalam Django. Pada akhirnya, anda akan mempunyai pemahaman yang jelas tentang masa untuk menggunakan JWT dan cara ia dibandingkan dengan pilihan lain seperti pengesahan berasaskan sesi dan token pengesahan. Mari selami!

Apakah itu JWT (Token Web JSON)?

JWT (JSON Web Token) ialah format token yang padat dan selamat URL yang digunakan untuk menghantar maklumat dengan selamat antara pihak. Ia biasanya digunakan dalam proses pengesahan di mana pelanggan meminta akses kepada sumber, seperti dalam web atau aplikasi mudah alih.

JWT terdiri daripada tiga bahagian:

Pengepala: Mengandungi metadata tentang token, seperti jenis (JWT) dan algoritma tandatangan (mis., HS256).

Muat bayar: Mengandungi tuntutan khusus pengguna, seperti ID pengguna, nama pengguna atau peranan.

Tandatangan: Memastikan token tidak diganggu dengan menandatangani pengepala dan muatan dengan kunci rahsia.

Sampel JWT mungkin kelihatan seperti ini:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6ImpvaG4iLCJleHAiOjE2MjEyMzY5MjZ9.GG7h8oV2C7Mcp93JK...

JWT biasanya digunakan dalam pengesahan tanpa negara, bermakna pelayan tidak menyimpan data sesi. Sebaliknya, semua maklumat (tuntutan) yang diperlukan dibenamkan dalam token itu sendiri.

Cara JWT Berfungsi: Proses Langkah demi Langkah

Mari kita pecahkan cara pengesahan JWT berfungsi dengan senario mudah:

1. Log Masuk Pengguna
Seorang pengguna menghantar e-mel dan kata laluan mereka melalui borang log masuk. Pelayan mengesahkan bukti kelayakan, dan jika ia betul, pelayan menjana JWT yang mengandungi maklumat pengguna (seperti id, nama pengguna dan peranan mereka).

2. Token Dihantar kepada Pelanggan
Sebaik sahaja JWT dijana, ia dihantar semula kepada pelanggan, biasanya dalam badan tindak balas. Pelanggan menyimpan token ini (dalam localStorage atau sessionStorage untuk penyemak imbas, atau dengan selamat pada peranti mudah alih).

3. Pengguna Meminta Sumber Dilindungi
Setiap kali pelanggan perlu mengakses laluan yang dilindungi, ia menghantar JWT dalam pengepala Kebenaran permintaan:

Authorization: Bearer <JWT_TOKEN>

Pelayan kemudiannya mengesahkan token, memastikan kesahihan dan integritinya, sebelum memberikan akses kepada sumber.

4. Tamat Tempoh dan Segarkan Token
Memandangkan token JWT mempunyai masa tamat tempoh (mis., 5 minit), setelah tamat tempoh, pengguna boleh menghantar token muat semula untuk mendapatkan JWT baharu tanpa perlu log masuk semula.

5. Pengguna Log Keluar
Apabila pengguna log keluar, token muat semula biasanya disenaraihitamkan (dalam persediaan yang menyokong penyenaraian hitam), memastikan pengguna log keluar dengan berkesan dan tidak boleh memuat semula token itu lagi.

JWT lwn Kaedah Pengesahan Tradisional dalam Django

JWT ialah salah satu daripada banyak cara untuk melaksanakan pengesahan dalam aplikasi Django. Mari kita lihat bagaimana JWT dibandingkan dengan kaedah biasa lain seperti pengurusan sesi dan token pengesahan.

1. Pengesahan JWT lwn Pengurusan Sesi

Pengurusan Sesi:
Dalam pengesahan berasaskan sesi, sebaik sahaja pengguna log masuk, pelayan mencipta sesi dan menyimpannya dalam pangkalan data atau memori. ID sesi kemudiannya dihantar kepada pelanggan melalui kuki. Pelanggan menyimpan ID sesi dan menghantarnya dengan setiap permintaan. Pelayan kemudiannya mendapatkan semula data sesi daripada storan untuk mengenal pasti pengguna.

Senario Dunia Sebenar:

Tapak Web E-dagang: Bayangkan anda log masuk ke kedai dalam talian, tambah item pada troli anda dan teruskan untuk membuat pembayaran. Setiap tindakan semasa sesi ini, seperti melihat produk atau mengemas kini troli, terikat pada ID sesi anda yang disimpan pada pelayan. Sebaik sahaja anda log keluar, sesi itu dimusnahkan.

JWT lwn. Sesi:

- Storan:

• JWT: Stateless, tiada storan sebelah pelayan. Semua data terkandung dalam token itu sendiri.
• Sesi: Stateful, pelayan menyimpan data sesi (biasanya dalam pangkalan data atau memori) dan ID sesi dihantar kepada klien.

- Kebolehskalaan:

• JWT: Sangat berskala; tidak perlu menyimpan maklumat sesi pengguna, menjadikannya mudah untuk menskala secara mendatar merentas pelayan.
• Sesi: Kurang berskala; memerlukan pengurusan dan perkongsian data sesi merentas pelayan (cth., menggunakan stor sesi berpusat).

- Pemindahan Data:

• JWT: Token termasuk semua data pengguna (tuntutan) dan dihantar dengan setiap permintaan. Ia boleh menjadi besar jika terlalu banyak data disertakan.
• Sesi: Hanya ID sesi dihantar dan data pengguna diambil daripada pelayan.

- Keselamatan:

• JWT: Terdedah jika token tidak disimpan dengan selamat pada klien (cth., storan setempat). Adalah penting untuk mengendalikan tamat tempoh token dan memuat semula dengan selamat.
• Sesi: Biasanya menggunakan kuki untuk menyimpan ID sesi, yang lebih selamat jika bendera HTTP sahaja dan Secure digunakan. Walau bagaimanapun, ia boleh terdedah kepada serangan CSRF.

- Tamat Tempoh & Pengurusan:

• JWT: Token mempunyai masa tamat tempoh. Jika token muat semula digunakan, token akses boleh diperbaharui tanpa pengesahan semula.
• Sesi: Sesi juga mempunyai tempoh tamat masa, tetapi boleh dilanjutkan dengan mudah selagi pengguna berinteraksi dengan apl.

- Saiz Token:

• JWT: Memandangkan semua data disertakan dalam token, JWT boleh menjadi lebih besar, terutamanya jika ia membawa banyak maklumat atau metadata pengguna.
• Sesi: Hanya ID sesi dihantar dengan setiap permintaan, jadi pemindahan data adalah minimum.

- Penggunaan:

• JWT: Diutamakan dalam API moden tanpa negara, aplikasi satu halaman (SPA) dan apl mudah alih.
• Sesi: Biasa dalam aplikasi web tradisional di mana pelayan menguruskan keadaan pengguna.

2. Pengesahan JWT lwn. Token Pengesahan

Token Pengesahan:
Dalam pengesahan berasaskan token (seperti Pengesahan Token terbina dalam Django), pelayan menjana token unik apabila pengguna log masuk. Token ini disimpan pada pelayan dan dihantar kepada klien, yang memasukkannya dalam setiap permintaan. Pelayan menyemak token dalam pangkalan data untuk mengesahkan pengguna.

Senario Dunia Sebenar:

Akses API: Pembekal API (seperti GitHub) menjana token API untuk pengguna selepas log masuk. Setiap kali anda berinteraksi dengan API GitHub, token dihantar dalam pengepala permintaan untuk mengesahkan permintaan .

JWT lwn. Token Auth:

- Storan Token

JWT (Token Web JSON):

Tanpa Negara: JWT adalah serba lengkap, bermakna semua maklumat (tuntutan) yang diperlukan disimpan dalam token itu sendiri. Pelayan tidak menyimpan token, yang menjadikannya sistem tanpa kewarganegaraan.
Token biasanya disimpan di bahagian pelanggan (cth., dalam localStorage, sessionStorage atau kuki) dan dihantar dengan setiap permintaan dalam pengepala Kebenaran.

Token Pengesahan:

Stateful: Dalam pengesahan berasaskan token tradisional, token dijana dan disimpan di bahagian pelayan (selalunya dalam pangkalan data). Pelayan menjejaki token dan pelanggan memasukkannya dalam setiap permintaan (biasanya dalam pengepala).

- Struktur Token

JWT:

Sendiri: Token JWT terdiri daripada tiga bahagian: pengepala, muatan dan tandatangan. Muatan mengandungi maklumat pengguna (seperti id, e-mel, peranan) dan ditandatangani untuk memastikan integriti.

Token Pengesahan:

Token Legap: Token Pengesahan biasanya rentetan legap, bermakna ia tidak membawa sebarang maklumat pengguna. Ia bertindak sebagai rujukan kepada sesi sisi pelayan atau data pengguna.
Pelayan menggunakan token ini untuk mencari sesi atau maklumat pengguna yang disimpan pada pelayan.

- Storan dan Skala Pelayan

JWT:

Tiada Storan Pelayan: Memandangkan token JWT adalah serba lengkap, pelayan tidak perlu menyimpan data sesi atau token. Ini menjadikannya sangat berskala, terutamanya dalam sistem teragih atau seni bina perkhidmatan mikro, di mana berbilang pelayan mungkin terlibat.

Token Pengesahan:

Storan Sisi Pelayan: Token Pengesahan disimpan dalam pangkalan data atau memori pada pelayan, yang bermaksud pelayan mesti menjejak dan mengesahkan token untuk setiap permintaan. Ini mungkin kurang berskala kerana pelayan perlu mengakses stor sesi pusat untuk setiap permintaan.

- Pertimbangan Keselamatan

JWT:

Berasaskan Tandatangan: Token JWT ditandatangani menggunakan algoritma seperti HS256 atau RS256 untuk memastikan token itu tidak diganggu. Walaupun ini melindungi integriti token, ia tidak menyulitkan data. Data sensitif tidak boleh dimasukkan dalam muatan melainkan disulitkan.

Risiko Bahagian Pelanggan: JWT selalunya disimpan dalam localStorage atau sessionStorage, yang boleh menyebabkan mereka terdedah kepada serangan XSS (Cross-Site Scripting). Untuk mengurangkan ini, ia boleh disimpan dalam kuki HTTP sahaja.

Token Pengesahan:

Pengesahan Bahagian Pelayan: Memandangkan token pengesahan tidak mengandungi maklumat pengguna dan disahkan terhadap sesi pada pelayan, token tersebut boleh dianggap lebih selamat daripada gangguan. Walau bagaimanapun, mereka terdedah kepada rampasan sesi atau serangan CSRF (Cross-Site Request Forgery) jika tidak dikendalikan dengan betul.

- Tamat Tempoh dan Jangka Hayat Token

JWT:

Token Akses Jangka Pendek: JWT biasanya mempunyai jangka hayat yang singkat (mis., 5–15 minit). Setelah tamat tempoh, pelanggan mesti menggunakan token muat semula untuk mendapatkan token akses baharu. Ini adalah bahagian penting model keselamatan JWT.
Token Segar Semula: Token penyegaran tahan lama membolehkan pengguna kekal log masuk tanpa memasukkan semula bukti kelayakan secara berterusan, tetapi ia juga datang dengan cabaran keselamatan mereka sendiri (cth., ia harus disimpan dan diurus dengan selamat).

Token Pengesahan:

Tiada Tamat Tempoh Token secara Lalai: Token Pengesahan tidak luput secara lalai melainkan dikendalikan secara eksplisit oleh pelayan. Pelayan boleh membatalkan atau tamat tempoh token, tetapi ini memerlukan logik dan storan tambahan untuk menjejaki tamat tempoh token.

- Saiz Token

JWT:

Saiz Token Lebih Besar: Memandangkan JWT mengandungi maklumat pengguna (tuntutan) dan tandatangan, mereka cenderung lebih besar berbanding dengan token pengesahan legap. Ini boleh meningkatkan sedikit penggunaan lebar jalur, terutamanya dalam senario dengan permintaan yang kerap.

Token Pengesahan:

Saiz Token Lebih Kecil: Token pengesahan biasanya rentetan legap, bermakna saiznya jauh lebih kecil. Mereka bertindak sebagai pengecam dan tidak membawa data tambahan, jadi mereka menggunakan kurang lebar jalur.

- Contoh Senario Penggunaan

JWT:

Aplikasi Halaman Tunggal (SPA): JWT berfungsi dengan baik dengan SPA (seperti React atau Angular) di mana anda memerlukan pengesahan tanpa kewarganegaraan dan tiada pengurusan sesi sebelah pelayan.

Perkhidmatan Mikro & API: JWT sesuai untuk API dan seni bina perkhidmatan mikro, di mana berbilang perkhidmatan perlu mengesahkan pengguna tanpa berkongsi keadaan sesi merentas pelayan.
Token Pengesahan:

Apl Web Tradisional: Dalam aplikasi web yang diberikan pelayan, token pengesahan (atau sesi) biasanya digunakan, kerana ia disimpan dan disahkan bahagian pelayan, menjadikannya sesuai untuk aplikasi yang mengekalkan sesi adalah mudah.
Aplikasi Berskala Kecil: Token Pengesahan berfungsi dengan baik untuk aplikasi dengan pengguna yang lebih sedikit, di mana pengurusan sesi tidak menjadi isu kebolehskalaan.

- Ketidaknegaraan vs. Kenegaraan

JWT:

Tanpa status: Memandangkan JWT tidak memerlukan storan sisi pelayan, mereka menjadikan aplikasi tanpa status. Ini berfaedah untuk menskalakan secara mendatar merentas berbilang pelayan kerana tidak ada keperluan untuk penyegerakan sesi antara pelayan.
Token Pengesahan:

Stateful: Token pengesahan memerlukan storan sesi sebelah pelayan, bermakna pelayan menjejaki data sesi. Ini baik untuk aplikasi kecil tetapi boleh menimbulkan masalah apabila menskala ke berbilang pelayan melainkan stor sesi pusat (seperti Redis) digunakan.

- Senarai Hitam dan Pembatalan

JWT:

Sukar untuk Dibatalkan: Memandangkan JWT tidak mempunyai kewarganegaraan dan tidak disimpan pada pelayan, sukar untuk membatalkannya sebaik sahaja dikeluarkan melainkan anda menggunakan penyenaraian hitam token. Ini bermakna jika token dikompromi, ia kekal sah sehingga tamat tempoh.

Penyenaraian Hitam Diperlukan: Untuk mengendalikan pembatalan token (cth., semasa log keluar), mekanisme senarai hitam mesti dilaksanakan pada pelayan untuk menjejaki token yang tidak sah.

Token Pengesahan:

Mudah Dibatalkan: Token pengesahan disimpan pada pelayan, jadi membatalkan atau membatalkannya adalah mudah.

3. Pengesahan JWT vs Pengesahan Asas

Pengesahan Asas:
Dalam pengesahan asas, pelanggan menghantar bukti kelayakan pengguna (nama pengguna dan kata laluan) dengan setiap permintaan, biasanya dikodkan dalam base64. Kaedah ini sering digunakan dalam sistem dalaman atau tetapan mudah.

Senario Dunia Sebenar:

Papan Pemuka Pentadbir Dalaman: Papan pemuka pentadbir dalaman syarikat kecil memerlukan pengguna log masuk dengan pengesahan asas. Apabila pengguna mengakses halaman, bukti kelayakan mereka dihantar dalam permintaan.

Kes Penggunaan Dunia Sebenar: Bila Menggunakan JWT?

Mari kita pertimbangkan contoh dunia sebenar: platform media sosial yang membolehkan pengguna log masuk, berinteraksi dengan siaran dan mengurus profil mereka merentas berbilang peranti.

Dalam sistem sedemikian:

1. JWT berfungsi dengan baik kerana ia tidak mempunyai kewarganegaraan, bermakna pelayan tidak perlu menyimpan sesi pengguna.
2. Pelanggan boleh menyimpan token secara setempat, yang membolehkan pengguna kekal log masuk merentas tab dan peranti yang berbeza.
3. Memandangkan apl mungkin menskala secara mendatar merentas berbilang pelayan (contohnya, satu pelayan untuk mengendalikan siaran dan satu lagi untuk profil), menggunakan JWT menjadikannya lebih mudah untuk membuat skala tanpa memerlukan stor sesi pusat.
4. Pengguna juga boleh memuat semula token mereka secara berkala untuk mengekalkan akses tanpa perlu log masuk semula.

Kesimpulan: Kaedah Pengesahan Mana Yang Perlu Dipilih?

Memilih kaedah pengesahan yang betul bergantung pada keperluan aplikasi anda:

JWT sesuai untuk aplikasi tidak bernegara dan berskala (seperti SPA, apl mudah alih dan perkhidmatan mikro).
Pengesahan berasaskan sesi berfungsi dengan baik untuk aplikasi web tradisional di mana kebolehskalaan bukanlah kebimbangan utama.
Token pengesahan ialah kaedah yang mudah dan selamat untuk pengesahan API skala kecil tempat storan token sebelah pelayan boleh diurus.

Setiap kaedah mempunyai kekuatan dan kelemahannya, tetapi JWT menyerlah kerana keupayaannya untuk mengendalikan sistem teragih moden yang berskala dan fleksibiliti adalah penting.

Atas ialah kandungan terperinci Pengesahan dan Keizinan - cara yang betul!. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!