Mengenai pengesahan bahagian hadapan, apakah maksud Token, Kuki, Sesi, JWT, log masuk tunggal, log masuk kod imbasan dan log masuk satu klik? Apakah fungsi setiap satu? Bagaimana anda biasanya melakukannya? Dan bagaimana anda menyimpannya? Jadi bagaimana anda memastikan ia selamat? Artikel berikut akan mengajar anda cara mengendalikan semua skim pengesahan di bahagian depan dan belakang, supaya anda tidak lagi keliru!
Saya masih ingat semasa temuduga, seorang penemuduga bertanya, berkenaan pengesahan front-end, apakah itu Token、Cookie、Session、JWT、单点登录? Apa yang ia lakukan? Bagaimana anda biasanya melakukannya? Dan bagaimana anda menyimpannya? Jadi bagaimana anda memastikan 它 selamat?
Setelah bertanya banyak soalan, saya sangat cemas dan terharu sehingga tidak dapat bercakap...
Sebenarnya, terdapat banyak kaedah pengesahan, seperti berikut saya telah meringkaskan 10种鉴权方法 yang biasa digunakan, jadi yang manakah sistem yang paling sesuai untuk anda? Mana satu yang paling selamat?
Kemudian marilah kita meneroka perlahan-lahan dan mencari jawapan daripada yang berikut ~
Sebelum memperkenalkan kaedah pengesahan, terlebih dahulu kita perlu memahami: 什么是认证、授权、鉴权、权限控制 dan hubungan antara mereka Dengan mereka sebagai asas, maka kita Hanya dalam ini bagaimana kita boleh mempunyai pemahaman yang menyeluruh dari awal hingga akhir~
认证(Identification) merujuk kepada mengesahkan identiti pengisytihar berdasarkan maklumat pengenalan unik pengisytihar.
dalam bahasa vernakular bermaksud: 你需要用身份证证明你自己是你自己.
Sebagai contoh, teknologi pengesahan biasa kami:
授权(Authorization): Dalam bidang keselamatan maklumat, ia merujuk kepada 资源所有者 delegasi 执行者, memberikan 执行者 kebenaran operasi sumber dalam julat yang ditentukan untuk memudahkan operasi berkaitan sumber.
Dalam bidang kehidupan sebenar, contohnya: Kad bank (diedarkan oleh bank), kad akses (diedarkan oleh pejabat pengurusan hartanah), kunci (diedarkan oleh tuan tanah), ini semua diberi kuasa dalam cara pelaksanaan kehidupan sebenar.
Dalam medan Internet, contohnya: Mekanisme sesi pelayan web, mekanisme kuki pelayar web dan pengeluaran token kebenaran (token) adalah semua mekanisme kebenaran.
鉴权(Authentication) Dalam bidang keselamatan maklumat, ia merujuk kepada proses mengenal pasti dan mengesahkan ketulenan pernyataan hak identiti yang diisytiharkan oleh pengisytihar.
Jika anda bermula dari kebenaran, lebih mudah untuk memahami pengesahan. Keizinan dan pengesahan ialah dua hubungan huluan dan hiliran yang sepadan Keizinan dahulu, kemudian pengesahan.
Dalam bidang kehidupan sebenar: Kad kawalan akses perlu melepasi pembaca kad akses dan kad bank perlu melepasi pengecam kad bank
Dalam medan Internet: Sahkan kesahihan dan kesahihan sesi/kuki/token
鉴权 ialah pautan antara yang sebelumnya dan yang seterusnya menerima output yang dibenarkan, mengesahkan kesahihannya dan kemudian mendapat kebenaran , ini akan bersedia untuk langkah seterusnya kawalan kebenaran.
权限控制(Access/Permission Control) Takrifkan operasi boleh laku sebagai senarai kebenaran, dan kemudian tentukan sama ada operasi itu dibenarkan/dilarang
Kawalan kebenaran boleh difahami dalam dua bahagian: satu ialah kebenaran , lain adalah kawalan. Kebenaran adalah konsep logik abstrak, manakala kawalan adalah kaedah pelaksanaan konkrit.
Dalam bidang kehidupan sebenar: Ambil pelaksanaan kebenaran kad kawalan akses sebagai contoh Kad kawalan akses mempunyai kebenaran untuk membuka semua pintu dalam syarikat mempunyai kebenaran peranan pentadbir , supaya anda boleh membuka semua pintu dalam syarikat.
Dalam medan Internet: Kawal akses antara muka melalui perkhidmatan hujung belakang web, membenarkan atau menolak permintaan akses.
Melihat perkara ini, kita harus faham bahawa empat pautan 认证, 授权, 鉴权 dan 权限控制 adalah hubungan 前后依次发生 dan 上下游; 🎜>
![[Perkongsian ringkasan] 10 kaedah pengesahan bahagian hadapan dan bahagian belakang yang biasa digunakan, jadi anda tidak akan keliru lagi](https://img.php.cn/upload/image/935/458/926/166124857181896%5BPerkongsian%20ringkasan%5D%2010%20kaedah%20pengesahan%20bahagian%20hadapan%20dan%20bahagian%20belakang%20yang%20biasa%20digunakan,%20jadi%20anda%20tidak%20akan%20keliru%20lagi "166124857181896[Perkongsian ringkasan] 10 kaedah pengesahan bahagian hadapan dan bahagian belakang yang biasa digunakan, jadi anda tidak akan keliru lagi")
Berikut ialah soalan kecil untuk semua orang fikirkan: Apakah hubungan antara pengesahan dan pengesahan? Semua orang dialu-alukan untuk berbincang di ruang komen
Sekarang kita telah memahami hubungan antara mereka, kita harus bercakap tentang pengesahan bahagian hadapan? Dan apakah perbezaan antara mereka?
Dalam HTTP, 基本认证方案（Basic Access Authentication) membenarkan pelanggan (biasanya pelayar web) untuk , identiti pengguna disahkan oleh pengguna memberikan nama pengguna dan kata laluan.
Oleh kerana hampir semua laman web dalam talian tidak menggunakan skim pensijilan ini, semua orang boleh memahami skim itu
1.1 Carta aliran pengesahan
1.2 Analisis langkah pengesahan
Klien (seperti penyemak imbas): meminta 受限的列表数据或资源 daripada pelayan Contohnya, medan adalah seperti berikut: Hello klien, sumber ini berada dalam zon keselamatan
GET /list/ HTTP/1.1 Host: www.baidu.com Authorization: Basic aHR0cHdhdGNoOmY=
dengan ialah mod pengesahan dan baidu.com menunjukkan bahawa pelanggan perlu memasukkan nama pengguna dan kata laluan domain keselamatan ini, bukan
www-Authenticate: Basic realm=”baidu.com”
BasicPelanggan: realm="baidu.com" Pelayan, saya telah berikan. anda nama pengguna dan kata laluan, sila lihat; (Nota: Jika pelanggan ialah penyemak imbas, tetingkap pop timbul ini akan muncul secara automatik, membenarkan pengguna memasukkan nama pengguna dan kata laluan); 🎜>Selepas memasukkan nama pengguna dan kata laluan, pelanggan akan menghantar nama pengguna dan kata laluan ke pelayan dalam penyulitan Base64
HTTP/1.1 401 Unauthorized www-Authenticate: Basic realm= "baidu.com"
Pelayan:
Pelanggan Hello, saya telah mengesahkan bahawa nama pengguna dan kata laluan anda dalam medan adalah betul adalah sumber yang anda mahukan.
GET /list/ HTTP/1.1 Authorization: Basic Ksid2FuZzp3YW5n==
1.3 KelebihanAuthorization
HTTP/1.1 200 OK ...
1.4 Kelemahan
Tidak Selamat: Kerana ia berdasarkan penghantaran HTTP , jadi ia hampir telanjang di Internet Walaupun ia menggunakan Base64 untuk mengekod, pengekodan ini boleh dinyahkod dengan mudah.
1.5 Senario penggunaan
2. Pengesahan Sesi-Kuki
Pengesahan menggunakan Sesi (sesi) pelayan dan Kuki penyemak imbas (klien) Dilaksanakan mod pengesahan komunikasi bahagian hadapan dan belakang.Session-Cookie2.1 Apakah itu Cookie
什么是 CookieSeperti yang kita sedia maklum, 什么是 Session (tiada memori untuk pemprosesan transaksi, setiap klien dan sesi pelayan selesai , pelayan tidak akan menyimpan sebarang maklumat sesi);
Jadi untuk membolehkan pelayan membezakan antara klien yang berbeza, ia mesti mengekalkan keadaan ini secara aktif untuk memberitahu pelayan sama ada kedua-dua permintaan sebelum dan selepas adalah daripada pelayar yang sama. Keadaan ini boleh dicapai melalui . Ciri-ciri:
2.2 Apakah itu Sesi
Konsep abstrak Sesi ialah session , ialah abstraksi interaksi antara pengguna dan pelayan untuk mencapai operasi gangguan/penerusan semasa proses komunikasi protokol tanpa kewarganegaraan
Khususnya , ia ialah struktur Sesi yang dijana oleh pelayan, yang boleh Disimpan dalam pelbagai cara, seperti memori, pangkalan data, fail, dsb. Tapak web yang besar biasanya mempunyai kluster pelayan Sesi khusus untuk menyimpan sesi pengguna
Proses prinsip:
Pelanggan: Pengguna menghantar permintaan kepada pelayan untuk kali pertama;
Klien: Penyemak imbas menerima respons untuk mendapatkan maklumat sesi, dan akan Membawa ID Sesi/Sesi dalam permintaan seterusnya; 🎜> Selepas pelayan mengekstraknya, ia akan membandingkannya dengan ID Sesi yang disimpan secara setempat untuk mencari sesi pengguna tertentu Kemudian mendapatkan status sesi; komunikasi antara pelanggan dan pelayan menjadi komunikasi stateful; dilakukan melalui protokol penyulitan pelayan sendiri;
Perbezaan daripada Kuki:
Kuki adalah disimpan di bahagian pelanggan dan boleh diusik sesuka hati, manakala Sesi disimpan di bahagian pelayan dan tidak boleh dipalsukan, jadi Sesi lebih selamat;
Jenis nilai akses adalah berbeza :Saiz storan berbeza: Data yang disimpan oleh kuki tidak boleh melebihi 4K; pelajar mungkin terfikir di sini, adakah
hanya menyimpan
Sahkan maklumat log masuk, pengesahan diluluskan Kemudian secara automatik; buat Sesi (simpan Sesi dalam memori atau dalam Redis), kemudian jana kelayakan identiti sesi rentetan pengenalan unik
Session-CookieSessionCookiePelayan:(biasa dipanggil ) untuk Sesi ini dan tambahkannya dalam pengepala respons Tetapkan pengecam unik ini dalam ;
Nota: Anda boleh menggunakan tandatangan untuk menyulitkan , dan pelayan akan menyahsulitnya berdasarkan kekunci yang sepadan (langkah pilihan)
Selepas menerima respons daripada pelayan, ia akan menghuraikan pengepala respons dan secara automatik menyimpan dalam kuki tempatan Pelayar adalah seperti berikut Semasa membuat HTTP permintaan, pengepala permintaan secara automatik akan disertakan dengan maklumat kuki di bawah nama domain;
, dan kemudian gunakan ini untuk mencari pelanggan yang disimpan oleh pelayan, dan kemudian tentukan sama ada permintaan itu sah; 2.5 Sesi -Kelebihan Kuki
Kuki adalah ringkas dan mudah digunakansession_idData sesi disimpan di bahagian pelayan, yang lebih mudah diurus berbanding JWT , iaitu, apabila pengguna log masuk dan Untuk log keluar secara aktif, anda hanya perlu menambah dan memadam Sesi yang sepadan, yang sesuai untuk pengurusansidSet-CookieHanya operasi bahagian belakang diperlukan, dan bahagian hadapan boleh dikendalikan tanpa sebarang rasa;
sidsecret2.6 Kelemahan Session-Cookie
2.7 Senario Penggunaan
2.8 Perpustakaan Sesi Disyorkan yang biasa digunakan pada bahagian hadapan
dan Penyelenggaraan Sesi menyebabkan masalah besar kepada pelayan. Adakah terdapat cara yang lebih baik? Session-Cookie
wujud Token
3.1 Apakah Token
ialah token . Apabila klien mengakses pelayan, pelayan akan mengeluarkan token selepas lulus pengesahan, klien boleh membawa token untuk mengakses pelayan hanya perlu mengesahkan kesahihan token. Token
Kelayakan sumber diperlukan untuk mengakses antara muka sumber (API)
Komposisi Token Am:
uid (identiti unik pengguna) masa (cap waktu masa semasa) tanda (tandatangan, beberapa digit pertama Token dimampatkan menjadi A perenambelasan rentetan panjang tertentu)
Carta alir pengesahan token:
Langkah-langkah pengesahan token Analisis:
Pelanggan: Masukkan nama pengguna dan kata laluan untuk meminta pengesahan log masuk; meminta untuk mengesahkan nama pengguna dan kata laluan; selepas pengesahan berjaya, pelayan akan mengeluarkan Token dan menghantar Token kepada pelanggan
Pelanggan: Selepas menerima Token; , ia perlu disimpan di bahagian web biasanya menyimpannya dalam localStorage atau Cookie, dan APP asli mudah alih biasanya disimpan dalam cache setempat; permintaan: Apabila meminta sumber API daripada pelayan, Token dihantar ke pelayan melalui medan Keizinan pengepala permintaan HTTP atau kaedah lain; > menerima permintaan, dan kemudian mengesahkan Token yang terkandung dalam permintaan pelanggan Jika pengesahan berjaya, data yang diminta akan dikembalikan kepada pelanggan, jika tidak, pemulangan akan ditolak (401); >
Pelayan tidak mempunyai kewarganegaraan dan mempunyai kebolehskalaan yang baik:
Menyokong peranti mudah alih APP
Mengelakkan serangan CSRF dengan berkesan (kerana kuki tidak diperlukan)
Sokong panggilan merentas program:Kelemahan Token:
![[Perkongsian ringkasan] 10 kaedah pengesahan bahagian hadapan dan bahagian belakang yang biasa digunakan, jadi anda tidak akan keliru lagi](https://img.php.cn/upload/image/786/431/696/166124856411728%5BPerkongsian%20ringkasan%5D%2010%20kaedah%20pengesahan%20bahagian%20hadapan%20dan%20bahagian%20belakang%20yang%20biasa%20digunakan,%20jadi%20anda%20tidak%20akan%20keliru%20lagi "166124856411728[Perkongsian ringkasan] 10 kaedah pengesahan bahagian hadapan dan bahagian belakang yang biasa digunakan, jadi anda tidak akan keliru lagi")
![[Perkongsian ringkasan] 10 kaedah pengesahan bahagian hadapan dan bahagian belakang yang biasa digunakan, jadi anda tidak akan keliru lagi](https://img.php.cn/upload/image/566/383/335/166124857782138%5BPerkongsian%20ringkasan%5D%2010%20kaedah%20pengesahan%20bahagian%20hadapan%20dan%20bahagian%20belakang%20yang%20biasa%20digunakan,%20jadi%20anda%20tidak%20akan%20keliru%20lagi "166124857782138[Perkongsian ringkasan] 10 kaedah pengesahan bahagian hadapan dan bahagian belakang yang biasa digunakan, jadi anda tidak akan keliru lagi")
![[Perkongsian ringkasan] 10 kaedah pengesahan bahagian hadapan dan bahagian belakang yang biasa digunakan, jadi anda tidak akan keliru lagi](https://img.php.cn/upload/image/192/758/195/166124858574844%5BPerkongsian%20ringkasan%5D%2010%20kaedah%20pengesahan%20bahagian%20hadapan%20dan%20bahagian%20belakang%20yang%20biasa%20digunakan,%20jadi%20anda%20tidak%20akan%20keliru%20lagi "166124858574844[Perkongsian ringkasan] 10 kaedah pengesahan bahagian hadapan dan bahagian belakang yang biasa digunakan, jadi anda tidak akan keliru lagi")
![[Perkongsian ringkasan] 10 kaedah pengesahan bahagian hadapan dan bahagian belakang yang biasa digunakan, jadi anda tidak akan keliru lagi](https://img.php.cn/upload/image/864/554/486/166124859229896%5BPerkongsian%20ringkasan%5D%2010%20kaedah%20pengesahan%20bahagian%20hadapan%20dan%20bahagian%20belakang%20yang%20biasa%20digunakan,%20jadi%20anda%20tidak%20akan%20keliru%20lagi "166124859229896[Perkongsian ringkasan] 10 kaedah pengesahan bahagian hadapan dan bahagian belakang yang biasa digunakan, jadi anda tidak akan keliru lagi")
sidSalah satu cara ialah: 另外一种办法是：再来一个 Token，一个专门生成 Access Token 的 Token，我们称为 Refresh Token；
Refresh Token 的认证流程图：
Refresh Token 认证步骤解析：
客户端： 输入用户名和密码请求登录校验；
服务端： 收到请求，验证用户名与密码；验证成功后，服务端会签发一个 Access Token 和 Refresh Token 并返回给客户端；
客户端： 把 Access Token 和 Refresh Token 存储在本地；
客户端发送请求： 请求数据时，携带 Access Token 传输给服务端；
服务端：
客户端 ( Access Token 已过期) ： 则重新传输 Refresh Token 给服务端；
服务端 ( Access Token 已过期) ： 验证 Refresh Token ，验证成功后返回新的 Access Token 给客户端；
客户端： 重新携带新的 Access Token 请求接口；
3.3 Token 和 Session-Cookie 的区别
Session-Cookie 和 Token 有很多类似的地方，但是 Token 更像是 Session-Cookie 的升级改良版。
如果你的用户数据可能需要和第三方共享，或者允许第三方调用 API 接口，用 Token 。如果永远只是自己的网站，自己的 App，用什么就无所谓了。
通过第三节，我们知道了 Token 的使用方式以及组成，我们不难发现，服务端验证客户端发送过来的 Token 时，还需要查询数据库获取用户基本信息，然后验证 Token 是否有效；
这样每次请求验证都要查询数据库，增加了查库带来的延迟等性能消耗；
那么这时候业界常用的 JWT 就应运而生了！！！
4.1 什么是 JWT
JWT 是 Auth0 提出的通过 对 JSON 进行加密签名来实现授权验证的方案；
就是登录成功后将相关用户信息组成 JSON 对象，然后对这个对象进行某种方式的加密，返回给客户端；
客户端在下次请求时带上这个 Token；
服务端再收到请求时校验 token 合法性，其实也就是在校验请求的合法性。
4.2 JWT 的组成
JWT 由三部分组成： Header 头部、 Payload 负载 和 Signature 签名
它是一个很长的字符串，中间用点（.）分隔成三个部分。列如 ：
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Header 头部：
在 Header 中通常包含了两部分：
![[Perkongsian ringkasan] 10 kaedah pengesahan bahagian hadapan dan bahagian belakang yang biasa digunakan, jadi anda tidak akan keliru lagi](https://img.php.cn/upload/image/724/427/748/166124859837135%5BPerkongsian%20ringkasan%5D%2010%20kaedah%20pengesahan%20bahagian%20hadapan%20dan%20bahagian%20belakang%20yang%20biasa%20digunakan,%20jadi%20anda%20tidak%20akan%20keliru%20lagi "166124859837135[Perkongsian ringkasan] 10 kaedah pengesahan bahagian hadapan dan bahagian belakang yang biasa digunakan, jadi anda tidak akan keliru lagi")
{
"alg": "HS256",
"typ": "JWT"
}Payload 负载：
它包含一些声明 Claim (实体的描述，通常是一个 User 信息，还包括一些其他的元数据) ，用来存放实际需要传递的数据，JWT 规定了7个官方字段：
除了官方字段，你还可以在这个部分定义私有字段，下面就是一个例子。
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}Signature 签名
Signature 部分是对前两部分的签名，防止数据篡改。
首先，需要指定一个密钥（secret）。这个密钥只有服务器才知道，不能泄露给用户。然后，使用 Header 里面指定的签名算法（默认是 HMAC SHA256），按照下面的公式产生签名。
HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)
4.3 JWT 的使用方式
客户端收到服务器返回的 JWT，可以储存在 Cookie 里面，也可以储存在 localStorage。
此后，客户端每次与服务器通信，都要带上这个 JWT。你可以把它放在 Cookie 里面自动发送，但是这样不能跨域，所以更好的做法是放在 HTTP 请求的头信息Authorization字段里面。
Authorization: Bearer <token></token>
4.4 JWT 的认证流程图
其实 JWT 的认证流程与 Token 的认证流程差不多，只是不需要再单独去查询数据库查找用户用户；简要概括如下：
4.5 JWT 的优点
4.6 JWT 的缺点
4.7 前端常用的 JWT 库推荐
前面我们已经知道了，在同域下的客户端/服务端认证系统中，通过客户端携带凭证，可以维持一段时间内的登录状态。
但随着企业的发展，一个大型系统里可能包含 n 多子系统，用户在操作不同的系统时，需要多次登录，很麻烦，那么单点登录（SSO) 就可以很好的解决这个问题的，在多个应用系统中，只需要登录一次，就可以访问其他相互信任的应用系统。
5.1 同域下的 SSO（主域名相同）
当百度网站存在两个相同主域名下的贴吧子系统 tieba.baidu.com 和网盘子系统 pan.baidu.com 时，以下为他们实现 SSO 的步骤：
客户端： 用户访问某个子系统时（例如 tieba.baidu.com），如果没有登录，则跳转至 SSO 认证中心提供的登录页面进行登录；
服务端： 登录认证后，服务端把登录用户的信息存储于 Session 中，并且附加在响应头的 Set-Cookie 字段中，设置 Cookie 的 Domain 为 .baidu.com ；
客户端：再次发送请求时，携带主域名 Domain 下的 Cookie 给服务器，此时服务端就可以通过该 Cookie 来验证登录状态了；
其实我们不难发现，这就是我们上面讲的
Session-Cookie 认证登录方式； 但如果是不同域呢？毕竟不同域之间 Cookie 是不共享的，那怎么办？
5.2 跨域下的 SSO（主域名不同）
Dalam laman web beli-belah biasa kami Tmall (tmall.com) dan Taobao (taobao.com), kami hanya perlu log masuk ke salah satu sistem, dan sistem lain akan log masuk secara lalai selepas membukanya kita buat ini?
Kemudian ada CAS（Central Authentication Service）中央授权服务, jadi mari kita bincangkan dahulu tentang proses CAS;
Carta alir pengesahan CAS di bawah log masuk tunggal:
Penjelasan terperinci tentang langkah pengesahan CAS di bawah log masuk tunggal:
Pelanggan: Mula mengakses sistem A;
Sistem A: Didapati bahawa pengguna tidak log masuk dan dialihkan ke perkhidmatan pengesahan CAS (sso.com) . Pada masa yang sama, parameter alamat URL berjaya membawa log masuk kemudian kembali ke pautan halaman sistem A (sso.com/login?redir…
Perkhidmatan pengesahan CAS: ditemui dalam kuki permintaan Tiada sijil tiket log masuk (TGC), jadi perkhidmatan pengesahan CAS menentukan bahawa pengguna berada dalam keadaan , mengubah hala halaman pengguna ke Antara muka log masuk CAS, dan pengguna melakukan operasi log masuk pada halaman log masuk CAS 🎜>未登录
Sahkan maklumat pengguna, Dan masukkan ke dalam Sesinya sendiri, dan tuliskannya dalam bentuk Set-Cookie di bawah domain yang Domainnya pada masa yang sama ,
dijana, dan kemudian diubah hala ke alamat sistem A. Alamat diubah hala mengandungi ST Dijana (alamat ubah hala:生成 TGCsso.com Sistem A: 授权令牌 ST (Service Ticket) memegang ST Hantar permintaan kepada perkhidmatan pengesahan CAS, dan perkhidmatan pengesahan CAS mengesahkan kesahihan tiket (ST Selepas pengesahan berjaya, Sistem A tahu bahawa pengguna telah log masuk ke CAS (ST boleh disimpan dalam Cookie atau setempat), dan pelayan Sistem A menggunakannya (ST) mencipta sesi dengan pengguna, dipanggil sesi separa dan mengembalikan sumber yang dilindungi 🎜>
Perkara yang perlu diperhatikan di bawah log masuk tunggal:
, Pengalihan terus sebenarnya lebih mudah untuk dicuri, jadi kami perlu menjana satu lagi Token pengesahan baharu selepas Sistem A atau Sistem B berjaya mengesahkan CAS (langkah 14 dan 11 dalam rajah) Kembali kepada klien untuk penyimpanan;Seperti yang ditunjukkan dalam proses dalam rajah, kami mendapati bahawa
selepas pengeluaran
CAS umumnya menyediakan empat antara muka:
CAS 认证服务: antara muka log masuk, digunakan untuk log masuk ke perkhidmatan kebenaran pusat授权令牌 ST
![[Perkongsian ringkasan] 10 kaedah pengesahan bahagian hadapan dan bahagian belakang yang biasa digunakan, jadi anda tidak akan keliru lagi](https://img.php.cn/upload/image/897/341/729/166124860695111%5BPerkongsian%20ringkasan%5D%2010%20kaedah%20pengesahan%20bahagian%20hadapan%20dan%20bahagian%20belakang%20yang%20biasa%20digunakan,%20jadi%20anda%20tidak%20akan%20keliru%20lagi "166124860695111[Perkongsian ringkasan] 10 kaedah pengesahan bahagian hadapan dan bahagian belakang yang biasa digunakan, jadi anda tidak akan keliru lagi")
![[Perkongsian ringkasan] 10 kaedah pengesahan bahagian hadapan dan bahagian belakang yang biasa digunakan, jadi anda tidak akan keliru lagi](https://img.php.cn/upload/image/323/229/797/166124861395999%5BPerkongsian%20ringkasan%5D%2010%20kaedah%20pengesahan%20bahagian%20hadapan%20dan%20bahagian%20belakang%20yang%20biasa%20digunakan,%20jadi%20anda%20tidak%20akan%20keliru%20lagi "166124861395999[Perkongsian ringkasan] 10 kaedah pengesahan bahagian hadapan dan bahagian belakang yang biasa digunakan, jadi anda tidak akan keliru lagi")
/login: Digunakan untuk membenarkan setiap Perkhidmatan mengesahkan sama ada pengguna telah log masuk ke perkhidmatan kebenaran pusat /logout/validate
/serviceValidateTGT (Ticket Grangting Ticket) TGC: Kuki Pemberian Tiket:
Pelayan CAS menjana TGT dan memasukkannya ke dalam Sesinya sendiri, dan TGC ialah pengecam unik (SessionId) bagi Sesi ini, yang diletakkan pada penyemak imbas dalam bentuk Kuki Ia adalah kelayakan yang digunakan oleh Pelayan CAS untuk mengenal pasti pengguna.登录票据
OAuth 协议又有 1.0 和 2.0 两个版本，2.0 版整个授权验证流程更简单更安全，也是目前最主要的用户身份验证和授权方式。
6.1 什么是 OAuth 2.0？
OAuth 是一个开放标准，允许用户授权第三方网站 (CSDN、思否等) 访问他们存储在另外的服务提供者上的信息，而不需要将用户名和密码提供给第三方网站；
常见的提供 OAuth 认证服务的厂商： 支付宝、QQ、微信、微博
简单说，OAuth 就是一种授权机制。数据的所有者告诉系统，同意授权第三方应用进入系统，获取这些数据。系统从而产生一个短期的进入令牌（Token），用来代替密码，供第三方应用使用。
令牌与密码的差异：
令牌（Token） 与 密码（Password） 的作用是一样的，都可以进入系统，但是有三点差异。
令牌是短期的，到期会自动失效： 用户自己无法修改。密码一般长期有效，用户不修改，就不会发生变化。
令牌可以被数据所有者撤销，会立即失效。
令牌有权限范围（scope）： 对于网络服务来说，只读令牌就比读写令牌更安全。密码一般是完整权限。
OAuth 2.0 对于如何颁发令牌的细节，规定得非常详细。具体来说，一共分成四种授权模式 （Authorization Grant） ，适用于不同的互联网场景。
无论哪个模式都拥有三个必要角色：客户端、授权服务器、资源服务器，有的还有用户（资源拥有者），下面简单介绍下四种授权模式。
6.2 授权码模式
授权码（Authorization Code Grant) 方式，指的是第三方应用先申请一个授权码，然后再用该码获取令牌。
这种方式是最常用的流程，安全性也最高，它适用于那些有后端服务的 Web 应用。授权码通过前端传送，令牌则是储存在后端，而且所有与资源服务器的通信都在后端完成。这样的前后端分离，可以避免令牌泄漏。
一句话概括：客户端换取授权码，客户端使用授权码换token，客户端使用token访问资源
客户端：
打开网站 A，点击登录按钮，请求 A 服务，A 服务重定向 (重定向地址如下) 至授权服务器 (如QQ、微信授权服务)。
https://qq.com/oauth/authorize? response_type=code& client_id=CLIENT_ID& redirect_uri=CALLBACK_URL& scope=read
上面 URL 中，response_type 参数表示要求返回授权码（code），client_id 参数让 B 知道是谁在请求，redirect_uri 参数是 B 接受或拒绝请求后的跳转网址，scope 参数表示要求的授权范围（这里是只读）
授权服务器：
授权服务网站 会要求用户登录，然后询问是否同意给予 A 网站授权。用户表示同意，这时授权服务网站 就会跳回 redirect_uri 参数指定的网址。跳转时，会传回一个授权码，就像下面这样。
https://a.com/callback?code=AUTHORIZATION_CODE
上面 URL 中，code 参数就是授权码。
网站 A 服务器：
拿到授权码以后，就可以向 授权服务器 (qq.com) 请求令牌，请求地址如下：
https://qq.com/oauth/token? client_id=CLIENT_ID& client_secret=CLIENT_SECRET& grant_type=authorization_code& code=AUTHORIZATION_CODE& redirect_uri=CALLBACK_URL
上面 URL 中，client_id 参数和 client_secret 参数用来让授权服务器 确认 A 的身份（client_secret 参数是保密的，因此只能在后端发请求），grant_type参数的值是AUTHORIZATION_CODE，表示采用的授权方式是授权码，code 参数是上一步拿到的授权码，redirect_uri 参数是令牌颁发后的回调网址。
授权服务器：
收到请求以后，验证通过，就会颁发令牌。具体做法是向 redirect_uri 指定的网址，发送一段 JSON 数据。
![[Perkongsian ringkasan] 10 kaedah pengesahan bahagian hadapan dan bahagian belakang yang biasa digunakan, jadi anda tidak akan keliru lagi](https://img.php.cn/upload/image/777/687/105/166124862745570%5BPerkongsian%20ringkasan%5D%2010%20kaedah%20pengesahan%20bahagian%20hadapan%20dan%20bahagian%20belakang%20yang%20biasa%20digunakan,%20jadi%20anda%20tidak%20akan%20keliru%20lagi "166124862745570[Perkongsian ringkasan] 10 kaedah pengesahan bahagian hadapan dan bahagian belakang yang biasa digunakan, jadi anda tidak akan keliru lagi")
![[Perkongsian ringkasan] 10 kaedah pengesahan bahagian hadapan dan bahagian belakang yang biasa digunakan, jadi anda tidak akan keliru lagi](https://img.php.cn/upload/image/106/332/573/166124863438329%5BPerkongsian%20ringkasan%5D%2010%20kaedah%20pengesahan%20bahagian%20hadapan%20dan%20bahagian%20belakang%20yang%20biasa%20digunakan,%20jadi%20anda%20tidak%20akan%20keliru%20lagi "166124863438329[Perkongsian ringkasan] 10 kaedah pengesahan bahagian hadapan dan bahagian belakang yang biasa digunakan, jadi anda tidak akan keliru lagi")
![1[Perkongsian ringkasan] 10 kaedah pengesahan bahagian hadapan dan bahagian belakang yang biasa digunakan, jadi anda tidak akan keliru lagi](https://img.php.cn/upload/image/429/532/130/166124864137884%5BPerkongsian%20ringkasan%5D%2010%20kaedah%20pengesahan%20bahagian%20hadapan%20dan%20bahagian%20belakang%20yang%20biasa%20digunakan,%20jadi%20anda%20tidak%20akan%20keliru%20lagi "166124864137884[Perkongsian ringkasan] 10 kaedah pengesahan bahagian hadapan dan bahagian belakang yang biasa digunakan, jadi anda tidak akan keliru lagi")
{
"access_token":"ACCESS_TOKEN",
"token_type":"bearer",
"expires_in":2592000,
"refresh_token":"REFRESH_TOKEN",
"scope":"read",
"uid":100101,
"info":{...}
}上面 JSON 数据中，access_token 字段就是令牌，A 网站在后端拿到了，然后返回给客户端即可。
6.3 隐藏式模式（Implicit Grant）
有些 Web 应用是纯前端应用，没有后端。这时就不能用上面的方式了，必须将令牌储存在前端。OAuth2.0 就规定了第二种方式，允许直接向前端颁发令牌。这种方式没有授权码这个中间步骤，所以称为（授权码）"隐藏式"（implicit）。
一句话概括：客户端让用户登录授权服务器换token，客户端使用token访问资源。
客户端：
打开网站 A，A 网站提供一个链接，要求用户跳转到 授权服务器，授权用户数据给 A 网站使用。如下链接：
https://qq.com/oauth/authorize? response_type=token& client_id=CLIENT_ID& redirect_uri=CALLBACK_URL& scope=read
上面 URL 中，response_type参数为token，表示要求直接返回令牌。
授权服务器：
用户跳转到授权服务器，登录后同意给予 A 网站授权。这时，授权服务器就会跳回redirect_uri 参数指定的跳转网址，并且把令牌作为 URL 参数，传给 A 网站。
https://a.com/callback#token=ACCESS_TOKEN
上面 URL 中，token参数就是令牌，A 网站因此直接在前端拿到令牌。
注意：
令牌的位置是 URL 锚点（fragment），而不是查询字符串（querystring），这是因为 OAuth 2.0 允许跳转网址是 HTTP 协议，因此存在"中间人攻击"的风险，而浏览器跳转时，锚点不会发到服务器，就减少了泄漏令牌的风险。
这种方式把令牌直接传给前端，是很不安全的。因此，只能用于一些安全要求不高的场景，并且令牌的有效期必须非常短，通常就是会话期间（session）有效，浏览器关掉，令牌就失效了。
6.4 用户名密码式模式（Password Credentials Grant）
如果你高度信任某个应用，OAuth 2.0 也允许用户把用户名和密码，直接告诉该应用。该应用就使用你的密码，申请令牌，这种方式称为"密码式"（password）。
一句话概括：用户在客户端提交账号密码换token，客户端使用token访问资源。
客户端：
A 网站要求用户提供 授权服务器(qq.com) 的用户名和密码。拿到以后，A 就直接向 授权服务器 请求令牌。
https://oauth.b.com/token? grant_type=password& username=USERNAME& password=PASSWORD& client_id=CLIENT_ID
上面 URL 中，grant_type参数是授权方式，这里的password表示"密码式"，username和password是 授权服务器 的用户名和密码。
授权服务器：
授权服务器 验证身份通过后，直接给出令牌。
注意，这时不需要跳转，而是把令牌放在 JSON 数据里面，作为 HTTP 回应，A 网站因此拿到令牌。
这种方式需要用户给出自己的用户名/密码，显然风险很大，因此只适用于其他授权方式都无法采用的情况，而且必须是用户高度信任的应用。
6.5 客户端模式（Client Credentials Grant）
客户端模式指客户端以自己的名义，而不是以用户的名义，向授权服务器 进行认证。
主要适用于没有前端的命令行应用。
一句话概括：客户端使用自己的标识换token，客户端使用token访问资源。
客户端：
客户端向授权服务器 进行身份认证，并要求一个访问令牌。请求链接地址：
https://oauth.b.com/token? grant_type=client_credentials& client_id=CLIENT_ID& client_secret=CLIENT_SECRET
上面 URL 中，grant_type参数等于client_credentials表示采用凭证式，client_id和client_secret用来让授权服务器 确认 A 的身份。
授权服务器：
授权服务器 验证通过以后，直接返回令牌。
注意：这种方式给出的令牌，是针对第三方应用的，而不是针对用户的，即有可能多个用户共享同一个令牌。
6.5 授权模式选型
| 模式 | 需要前端 | 需要后端 | 需要用户响应 | 需要客户端密钥 |
|---|---|---|---|---|
| 授权码模式 Authorization Code | ✅ | ✅ | ✅ | ✅ |
| 隐式授权模式 Implicit Grant | ✅ | ❌ | ✅ | ❌ |
| 密码授权模式 Password Grant | ✅ | ✅ | ✅ | ✅ |
| 客户端授权模式 Client Credentials | ❌ | ✅ | ❌ | ✅ |
Perkara di atas adalah agak mudah Asasnya logik OAuth2.0 dijelaskan Jika anda ingin mengetahui dengan lebih terperinci, anda boleh melihat dokumen rasmi OAuth atau RFC 6749 anda juga boleh melihat OAuth 2.0 konsep dan ringkasan proses kebenaran Bandingkan
<.>
7.1 Apakah itu log masuk bersama
Ia merujuk kepada perkhidmatan log masuk yang merangkumi pengesahan kelayakan berbilang di Pada masa yang sama, ia juga boleh difahami Perkhidmatan log masuk yang menggunakan bukti kelayakan pihak ketiga untuk pengesahan. 联合登录
Dalam istilah orang awam: Untuk dua tapak web A dan B, gunakan akaun dan kata laluan tapak web B semasa melog masuk ke tapak web A, iaitu log masuk bersama, atau gunakan tapak web A semasa log masuk masuk ke laman web B. Kata laluan akaun juga merupakan log masuk bersama. Konsep
sebenarnya serupa dengan kaedah pengesahan OAuth2.0 yang dinyatakan di atas. 用户名密码式模式
7.2 Apakah log masuk yang dipercayai
merujuk kepada semua log masuk yang tidak memerlukan penyertaan aktif pengguna, seperti yang ditetapkan antara peranti peribadi dan pengguna Hubungan yang mengikat antara mereka ialah bukti kelayakan adalah maklumat peranti peribadi, dan pengguna tidak perlu memberikan bukti kelayakan tambahan pada masa ini. Log masuk yang dipercayai juga merujuk kepada menggunakan pustaka pengguna pihak ketiga yang agak matang untuk mengesahkan kelayakan dan log masuk ke tapak web yang sedang anda lawati. 信任登录
Dalam istilah orang awam: Apabila tapak web A dilog masuk, anda boleh melompat terus ke tapak web B tanpa log masuk, iaitu . 信任登录
Saya mahu membolehkan pengguna log masuk hanya pada satu peranti . Pengguna dilarang log masuk berulang kali; !
Log masuk unik merujuk kepada melarang berbilang orang daripada log masuk ke akaun yang sama pada masa yang sama, tingkah laku log masuk yang terakhir akan menyebabkan yang pertama pergi ke luar talian.
Ringkasnya : Selepas akaun A log masuk pada komputer A, akaun A log masuk semula menggunakan komputer B. Apabila komputer A meminta halaman, ia akan menggesa "Mulakan Semula Maklumat "Log Masuk" dan lompat ke halaman log masuk
8.2 Carta aliran log masuk unik
8.3 Penjelasan terperinci tentang langkah log masuk unik
Operasi pengguna pada klien A:
Masukkan akaun minta antara muka Log masuk;
Pengguna beroperasi pada klien B:
Log masuk kod QR imbasan biasanya ditemui dalam APP mudah alih Banyak laman web PC menyediakan fungsi pengimbasan log masuk kod QR Tidak perlu memasukkan sebarang akaun dan kata laluan pada halaman web Anda hanya perlu mendayakan sebagai WeChat, Taobao, QQ, dsb.) dsb.) Cara untuk pengguna log masuk mengimbas secara aktif 二维码 dan kemudian mengesahkan log masuk supaya aplikasi yang sama pada PC boleh log masuk dengan cepat ialah 扫码登录.
9.2 Apakah itu kod QR
二维码 Juga dikenali sebagai kod QR, kod QR biasa ialah Kod QR, nama penuh QR Quick Response ialah kaedah pengekodan yang telah menjadi sangat popular pada peranti mudah alih sejak beberapa tahun kebelakangan ini. Ia boleh menyimpan lebih banyak maklumat dan mewakili lebih banyak jenis data daripada Kod Bar tradisional.
Melalui perkara di atas, tidak sukar untuk mencari bahawa mengimbas kod QR untuk log masuk memerlukan kerjasama tiga terminal (PC端, 手机端, 服务端) untuk mencapai log masuk yang berjaya;
9.3 Carta alir pengesahan untuk mengimbas kod QR untuk log masuk
9.4 Penjelasan terperinci daripada langkah-langkah untuk mengimbas kod QR untuk log masuk ( Peringkat untuk diimbas, peringkat untuk disahkan, peringkat disahkan)
Peringkat untuk diimbas:
Sebelah PC:
Buka portal log masuk kod imbasan tapak web (seperti taobao.com) atau APP (seperti WeChat a.); permintaan akan dihantar ke pelayan dengan maklumat peranti sebelah PC permintaan kod QR; permintaan, ia secara rawak menjana UUID sebagai ID kod QR, dan Kaitkan UUID dengandan simpannya dalam pelayan Redis, dan kemudian kembalikan ke PC pada masa yang sama, tetapkan masa tamat tempoh , kod QR log masuk pengguna perlu dimuat semula dan diperoleh semula.
PC:
Selepas menerima ID kod QR, paparkan ID kod QR dengan PC 端的设备信息 dan tunggu terminal mudah alih mengimbas kod. Dan pada masa ini, PC mula mengundi untuk menanyakan status kod QR sehingga log masuk berjaya.
Kod diimbas menunggu pengesahan:
二维码的形式
Buka APP yang sepadan dengan log masuk
pada telefon mudah alih (WeChat atau Taobao, dsb.) dan mula mengimbas dan mengenal pasti kod QR yang dipaparkan pada PC;
Pelayan:
Selepas menerima permintaan daripada telefon bimbit, ia akan mengaitkanMengapa ia perlu dikaitkan? Kerana apabila kita menggunakan WeChat dan log keluar pada terminal mudah alih, terminal PC juga harus log keluar Persatuan ini memainkan peranan ini. Kemudian Token sementara akan dijana, yang akan dikembalikan ke terminal mudah alih, dan Token sekali akan digunakan sebagai baucar untuk pengesahan.
Peringkat yang disahkan:
Token 与二维码 ID
Terima Selepas menerima maklumat pengesahan, klik butang pengesahan, dan terminal mudah alih akan membawa yang diperoleh dalam langkah sebelumnya dan menghantarnya ke pelayan untuk pengesahan; :
akan dijana untuk bahagian PC Selepas itu, pihak PC akan memegang Token ini untuk mengakses bahagian pelayan.
临时 Token Bahagian PC:
10 Log masuk satu klik (terpakai untuk APP asli) 正式的 Token
Seperti yang kita sedia maklum, kaedah log masuk yang paling tradisional ialah log masuk dengan akaun dan kata laluan, mudah dan kasar, secara amnya tidak akan ada masalah
Kelemahan:Tetapi kaedah ini memerlukan; pengguna untuk mengingati diri mereka Nombor akaun dan kata laluan mempunyai kos memori. Untuk mengurangkan kos memori, pengguna mungkin menggunakan set kata laluan akaun yang sama pada platform yang berbeza. Dari perspektif keselamatan, sebaik sahaja kata laluan akaun platform tertentu dibocorkan, platform lain yang digunakan oleh pengguna akan terjejas.
Selain itu, memandangkan akaun itu tiada kaitan dengan identiti peribadi, ini bermakna pengguna yang sama boleh mendaftarkan berbilang akaun berbeza, yang bermaksud pendaftaran berniat jahat mungkin berlaku.
Sehingga sistem nama sebenar wajib untuk kad telefon mudah alih diselesaikan!
10.2 Log masuk kod pengesahan nombor telefon bimbit
Dengan pembangunan Internet wayarles dan promosi sistem nama sebenar kad telefon bimbit, nombor telefon mudah alih mempunyai menjadi bukti identiti khas Berbanding dengan kata laluan akaun, nombor telefon mudah alih boleh mengesahkan identiti pengguna dengan lebih baik dan mencegah pendaftaran berniat jahat.
Walau bagaimanapun, pendaftaran nombor telefon bimbit masih memerlukan beberapa siri operasi yang membosankan: masukkan nombor telefon bimbit, tunggu kod pengesahan SMS, masukkan kod pengesahan, dan klik untuk log masuk. Keseluruhan proses mengambil masa sekurang-kurangnya dua puluh saat, dan jika anda tidak menerima mesej teks, anda perlu log masuk untuk menebusnya Masalah seperti ini boleh menyebabkan kehilangan pengguna.
Dari perspektif keselamatan, terdapat juga risiko kebocoran kod pengesahan. Jika seseorang mengetahui nombor telefon mudah alih anda dan mencuri kod pengesahan, dia juga boleh log masuk ke akaun anda.
Jadi terdapat operasi log masuk satu klik!
10.3 Apakah itu log masuk satu klik
Mari kita fikirkan, mengapa kita memerlukan kod pengesahan? Fungsi kod pengesahan adalah untuk mengesahkan bahawa nombor telefon bimbit adalah milik anda Selain menggunakan mesej teks, adakah terdapat cara lain untuk mengesahkan nombor telefon bimbit?
Jadi, protagonis kami boleh log masuk dengan satu klik.
Fungsi kod pengesahan SMS adalah untuk membuktikan bahawa pengguna halaman operasi semasa dan pengguna yang memasukkan nombor telefon bimbit adalah orang yang sama, selagi kita boleh mendapatkan telefon bimbit tersebut nombor kad yang digunakan oleh telefon bimbit semasa, kami boleh terus menggunakan nombor ini untuk log masuk. , tiada operasi tambahan diperlukan, ini adalah log masuk satu klik.
Sama ada log masuk satu klik boleh dilakukan bergantung pada sama ada pengendali membuka perkhidmatan berkaitan semasa pengendali membuka perkhidmatan berkaitan, kami kini boleh mengakses SDK yang disediakan oleh pengendali dan membayar untuk menggunakan perkhidmatan berkaitan.
Carta aliran log masuk satu klik:
![1[Perkongsian ringkasan] 10 kaedah pengesahan bahagian hadapan dan bahagian belakang yang biasa digunakan, jadi anda tidak akan keliru lagi](https://img.php.cn/upload/image/702/609/582/1661248678529660.png "1661248678529660.png")
Penjelasan terperinci tentang langkah log masuk satu klik:
Pengamatan SDK: Panggil kaedah SDK dan masukkan AppKey dan AppSecret yang dikonfigurasikan oleh platform
Memanggil halaman kebenaran: Panggil SDK untuk menggunakan antara muka kebenaran SDK akan memulakan permintaan kepada operator untuk mendapatkan topeng nombor telefon mudah alih Selepas permintaan berjaya, ia akan melompat ke halaman kebenaran. Halaman kebenaran akan memaparkan topeng nombor telefon mudah alih dan perjanjian operator untuk pengesahan pengguna.
Bersetuju dengan kebenaran dan log masuk: Pengguna bersetuju dengan perjanjian yang berkaitan dan mengklik butang log masuk pada halaman kebenaran SDK akan meminta Token kali ini. Selepas permintaan berjaya, Token akan dihantar kepada pengguna Kembali kepada pelanggan
Dapatkan nombor: Hantar Token yang diperolehi kepadanya. pelayan sendiri, dan pelayan akan membawa Token dan memanggil antara muka log masuk satu klik pengendali Jika panggilan berjaya, nombor telefon bimbit akan dikembalikan. Pelayan menggunakan nombor telefon mudah alih untuk log masuk atau mendaftar, dan mengembalikan hasil operasi kepada pelanggan untuk melengkapkan log masuk satu klik.
Tiga platform terbuka pengendali utama:
Platform Terbuka China Unicom-WO
Memandangkan tiga pengendali domestik utama masing-masing mempunyai SDK bebas, kerja keserasian akan menjadi sangat rumit. Jika anda ingin menggunakan penyelesaian log masuk satu klik, anda mungkin ingin menggunakan pihak ketiga untuk menyediakan perkhidmatan pengesahan nombor Pembekal berikut mempunyai keupayaan pengesahan nombor telefon mudah alih:
Nota:
Semasa proses pengesahan, pengguna dikehendaki menghidupkan rangkaian selular peranti mudah alih tidak mempunyai kad SIM dimasukkan, atau rangkaian selular dimatikan Dalam kes rangkaian, pengesahan tidak dapat diselesaikan. Oleh itu, walaupun log masuk satu klik didayakan, ia masih perlu serasi dengan kaedah log masuk tradisional, membolehkan pengguna masih melengkapkan proses log masuk secara normal sekiranya berlaku kegagalan.
Setelah mempelajari dan memahami 10 kaedah pengesahan di atas, mari kita ringkaskan secara ringkas
![1[Perkongsian ringkasan] 10 kaedah pengesahan bahagian hadapan dan bahagian belakang yang biasa digunakan, jadi anda tidak akan keliru lagi](https://img.php.cn/upload/image/708/704/961/166124864761691%5BPerkongsian%20ringkasan%5D%2010%20kaedah%20pengesahan%20bahagian%20hadapan%20dan%20bahagian%20belakang%20yang%20biasa%20digunakan,%20jadi%20anda%20tidak%20akan%20keliru%20lagi "166124864761691[Perkongsian ringkasan] 10 kaedah pengesahan bahagian hadapan dan bahagian belakang yang biasa digunakan, jadi anda tidak akan keliru lagi")
![1[Perkongsian ringkasan] 10 kaedah pengesahan bahagian hadapan dan bahagian belakang yang biasa digunakan, jadi anda tidak akan keliru lagi](https://img.php.cn/upload/image/868/412/865/166124865346521%5BPerkongsian%20ringkasan%5D%2010%20kaedah%20pengesahan%20bahagian%20hadapan%20dan%20bahagian%20belakang%20yang%20biasa%20digunakan,%20jadi%20anda%20tidak%20akan%20keliru%20lagi "166124865346521[Perkongsian ringkasan] 10 kaedah pengesahan bahagian hadapan dan bahagian belakang yang biasa digunakan, jadi anda tidak akan keliru lagi")
![1[Perkongsian ringkasan] 10 kaedah pengesahan bahagian hadapan dan bahagian belakang yang biasa digunakan, jadi anda tidak akan keliru lagi](https://img.php.cn/upload/image/259/197/687/166124866070097%5BPerkongsian%20ringkasan%5D%2010%20kaedah%20pengesahan%20bahagian%20hadapan%20dan%20bahagian%20belakang%20yang%20biasa%20digunakan,%20jadi%20anda%20tidak%20akan%20keliru%20lagi "166124866070097[Perkongsian ringkasan] 10 kaedah pengesahan bahagian hadapan dan bahagian belakang yang biasa digunakan, jadi anda tidak akan keliru lagi")
![1[Perkongsian ringkasan] 10 kaedah pengesahan bahagian hadapan dan bahagian belakang yang biasa digunakan, jadi anda tidak akan keliru lagi](https://img.php.cn/upload/image/425/646/298/166124866574690%5BPerkongsian%20ringkasan%5D%2010%20kaedah%20pengesahan%20bahagian%20hadapan%20dan%20bahagian%20belakang%20yang%20biasa%20digunakan,%20jadi%20anda%20tidak%20akan%20keliru%20lagi "166124866574690[Perkongsian ringkasan] 10 kaedah pengesahan bahagian hadapan dan bahagian belakang yang biasa digunakan, jadi anda tidak akan keliru lagi")
![1[Perkongsian ringkasan] 10 kaedah pengesahan bahagian hadapan dan bahagian belakang yang biasa digunakan, jadi anda tidak akan keliru lagi](https://img.php.cn/upload/image/188/959/138/166124867037607%5BPerkongsian%20ringkasan%5D%2010%20kaedah%20pengesahan%20bahagian%20hadapan%20dan%20bahagian%20belakang%20yang%20biasa%20digunakan,%20jadi%20anda%20tidak%20akan%20keliru%20lagi "166124867037607[Perkongsian ringkasan] 10 kaedah pengesahan bahagian hadapan dan bahagian belakang yang biasa digunakan, jadi anda tidak akan keliru lagi")
HTTP 基本认证Sesuai untuk rangkaian dalaman, atau rangkaian yang tidak mempunyai keperluan keselamatan yang sangat tinggi; Session-Cookie sesuai untuk kebanyakan tapak web perusahaan di pasaran, dan prestasi JWT akan lebih baik daripada Token Token sesuai untuk tapak web perusahaan besar dengan banyak subsistem; >JWT
单点登录OAuth 2.0
扫码登录一键登录)
Bagaimana untuk membuka vsd file
Kaedah penukaran kata laluan MySQL
Muat turun aplikasi Yiou Exchange
Penjelasan terperinci tentang konfigurasi nginx
Bagaimana untuk membuat halaman web dalam python
Bagaimana untuk menyelesaikan masalah bahawa Apple tidak boleh memuat turun lebih daripada 200 fail
Bagaimana untuk menyelesaikan aksara filezilla yang kacau
Apakah kaedah untuk memulakan semula aplikasi dalam Android?
![[Web front-end] Permulaan pantas Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
