[Perkongsian ringkasan] 10 kaedah pengesahan bahagian hadapan dan bahagian belakang yang biasa digunakan, jadi anda tidak akan keliru lagi

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 ~

Apakah yang akan anda pelajari melalui artikel ini?

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~

Apakah pensijilan?

认证(Identification) merujuk kepada mengesahkan identiti pengisytihar berdasarkan maklumat pengenalan unik pengisytihar.

dalam bahasa vernakular bermaksud: 你需要用身份证证明你自己是你自己.

Sebagai contoh, teknologi pengesahan biasa kami:

• kad ID
• Nama pengguna dan kata laluan
• Telefon mudah alih pengguna: mesej teks telefon mudah alih, pengimbasan kod QR telefon bimbit , Kata laluan gerak isyarat
• Alamat e-mel pengguna
• Ciri biologi pengguna: cap jari, suara, iris mata
• Pengenalpastian data besar pengguna
• dll .

Apakah itu kebenaran?

授权(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.

Apakah itu pengesahan?

鉴权(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.

Apakah itu 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.

Apakah hubungan antara pengesahan, kebenaran, pengesahan dan kawalan kebenaran?

Melihat perkara ini, kita harus faham bahawa empat pautan 认证, 授权, 鉴权 dan 权限控制 adalah hubungan 前后依次发生 dan 上下游; 🎜>

Perlu diingatkan bahawa keempat-empat pautan ini kadangkala berlaku pada masa yang sama. Contohnya, dalam adegan berikut:

• Gunakan kad akses untuk membuka pintu: Empat pautan pengesahan, kebenaran, pengesahan dan kawalan kebenaran berada dalam satu masa, berlaku serentak dalam sekelip mata
• Log masuk tapak web pengguna: Apabila pengguna log masuk menggunakan nama pengguna dan kata laluan, pengesahan dan kebenaran dilengkapkan bersama, manakala pengesahan dan kawalan kebenaran berlaku semasa permintaan akses berikutnya, seperti semasa memilih item atau membuat pembayaran.

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?

1. Pengesahan asas HTTP

---

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

  dan merupakan sumber terhad yang memerlukan asas. pengesahan;

   GET /list/ HTTP/1.1
   Host: www.baidu.com
   Authorization: Basic aHR0cHdhdGNoOmY=

mengembalikan kod status 401 (Tidak dibenarkan) kepada klien dan menyediakan domain Pengesahan
• memerlukan pengesahan identiti

  dengan ialah mod pengesahan dan baidu.com menunjukkan bahawa pelanggan perlu memasukkan nama pengguna dan kata laluan domain keselamatan ini, bukan

  domain lain

  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"

  Format penghantaran adalah seperti berikut (Kandungan asas ialah:
nama pengguna:kata laluan dalam ase64 format
• ):
  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
   ...

  Mudah, pada asasnya disokong oleh semua pelayar popular

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.

Walaupun kandungan pengesahan tidak boleh dinyahkodkan ke dalam nama pengguna dan kata laluan asal, ia adalah tidak selamat pengguna berniat jahat boleh mendapatkan kandungan pengesahan dan kemudian menggunakan pelayan perkongsian berterusan mereka untuk memulakan permintaan menyerang.

• Tidak dapat log keluar secara aktif
  • :
  • Memandangkan protokol HTTP tidak menyediakan mekanisme untuk mengosongkan pengesahan Asas maklumat dalam penyemak imbas, melainkan tab atau penyemak imbas ditutup, atau pengguna mengosongkan sejarah.

• 1.5 Senario penggunaan
  Rangkaian dalaman, atau rangkaian yang tidak mempunyai keperluan keselamatan yang sangat tinggi .

2. Pengesahan Sesi-Kuki

Pengesahan menggunakan Sesi (sesi) pelayan dan Kuki penyemak imbas (klien) Dilaksanakan mod pengesahan komunikasi bahagian hadapan dan belakang.

Sebelum memahami ayat ini, mari kita fahami secara ringkas dan ?

---

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:

• Cookies disimpan di sebelah pelanggan dan boleh diusik sesuka hati mereka tidak selamat
• Ada had saiz, maksimum 4kb
• Ada. had kuantiti. Secara amnya, satu penyemak imbas hanya boleh tidak lebih daripada 20 kuki boleh disimpan, dan penyemak imbas biasanya hanya membenarkan 300 kuki
• Android dan IOS tidak menyokong kuki dengan baik
• Kuki tidak bersilang- domain, tetapi nama domain peringkat pertama dan nama domain peringkat kedua Nama domain peringkat dibenarkan untuk kegunaan dikongsi (bergantung pada domain)

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;

Pelayan:
• menerima data dan menciptanya secara automatik untuk ID Sesi/Sesi Khusus pengguna untuk mengenal pasti pengguna dan menjejaki proses sesi semasa pengguna;

  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:

• Keselamatan:

  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 :
Kuki hanya menyokong data rentetan, dan Sesi boleh menyimpan sebarang jenis data

• Tempoh sah adalah berbeza:
Kuki boleh ditetapkan Untuk mengekalkannya dalam jangka masa yang lama, Sesi biasanya mempunyai masa tamat tempoh yang lebih pendek;

Saiz storan berbeza: Data yang disimpan oleh kuki tidak boleh melebihi 4K; pelajar mungkin terfikir di sini, adakah

hanya menyimpan

dalam
• pada pelanggan?
• Bingo

, memang begitulah keadaannya, mari kita lihat di bawah

2.3 Carta aliran pengesahan Sesi-Kuki
• 2.4 Analisis Langkah-langkah Pengesahan Sesi-Kuki
Pelanggan:

Hantar maklumat log masuk nama pengguna/kata laluan ke pelayan untuk meminta pengesahan log masuk

Session-CookieSessionCookiePelayan:

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

(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)

Pelanggan:

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;

Pelayan:
• akan menghuraikan pengepala permintaan Kuki apabila menerima permintaan pelanggan.

  , 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;

  sid secret2.6 Kelemahan Session-Cookie

• Bergantung pada Kuki Setelah pengguna melumpuhkan Kuki pada penyemak imbas, maka GG Smecta hilang
• Kuki mendedahkan data dalam penyemak imbas, meningkatkan risiko kecurian data. Risiko (mudah diserang oleh CSRF, dsb.);
• Sesi disimpan pada pelayan, yang meningkatkan overhed pelayan Apabila bilangan pengguna ramai, ia akan mengurangkan prestasi pelayan dengan ketara
Sokongan untuk terminal mudah alih Tidak mesra seksual;

2.7 Senario Penggunaan

Terpakai pada tapak web umumnya sederhana dan besar (kecuali APP mudah alih) ;
• Memandangkan sesi umum perlu disimpan secara berpusat pada pelayan memori (seperti Redis), ini akan meningkatkan belanjawan pelayan, jadi jika belanjawan tidak mencukupi, sila pilih dengan teliti ;

2.8 Perpustakaan Sesi Disyorkan yang biasa digunakan pada bahagian hadapan

Gunakan ekspres:
• sesi-ekspres
Gunakan koa:
• koa -sesi

3 pengesahan Token

---

Sekarang. kami telah mengetahui bahawa beberapa kelemahan

dan Penyelenggaraan Sesi menyebabkan masalah besar kepada pelayan. Adakah terdapat cara yang lebih baik? Session-Cookie


Kemudian

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

Ringkasan dalam satu ayat;

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); >

Kelebihan Token:

• Pelayan tidak mempunyai kewarganegaraan dan mempunyai kebolehskalaan yang baik:
Mekanisme Token tidak memerlukan storan sesi di bahagian pelayan ( Sesi), kerana Token itu sendiri mengandungi maklumat yang berkaitan dengan pengguna yang dikenal pasti, yang sesuai untuk berkongsi status pengguna antara pelbagai perkhidmatan

• Menyokong peranti mudah alih APP

• Keselamatan yang baik:

  Mengelakkan serangan CSRF dengan berkesan (kerana kuki tidak diperlukan)

  Sokong panggilan merentas program:
Kerana kuki tidak membenarkan akses merentas domain dan Token tidak mempunyai masalah ini

Kelemahan Token:

• Kerjasama:
Memerlukan front-end dan back-end kerjasama;
• Lebar jalur diduduki:
Dalam keadaan biasa, ia lebih besar daripada
• , menggunakan lebih banyak trafik dan menduduki lebih lebar jalur
Isu prestasi:
• Walaupun token disahkan Tidak perlu mengakses pangkalan data atau perkhidmatan jauh untuk pengesahan kebenaran, tetapi operasi seperti penyulitan dan penyahsulitan Token diperlukan, jadi ia akan menggunakan lebih banyak prestasi
Kesahan pendek tempoh:
Untuk mengelakkan Token dicuri, Secara amnya, tempoh sah Token akan ditetapkan lebih pendek, jadi terdapat
3.2 Apakah itu Refresh Token? >
• Token yang digunakan untuk pengesahan oleh antara muka perniagaan, kami memanggilnya .
Atas sebab keselamatan, tempoh sah
• kami biasanya ditetapkan menjadi lebih pendek untuk mengelak daripada dicuri. Walau bagaimanapun, tempoh sah yang terlalu singkat akan menyebabkan kerap tamat tempoh Apakah yang perlu saya lakukan selepas tamat tempoh? sidSalah satu cara ialah:
, sangat menyusahkan untuk membenarkan pengguna log masuk semula untuk mendapatkan Token baharu;

另外一种办法是：再来一个 Token，一个专门生成 Access Token 的 Token，我们称为 Refresh Token；

• Access Token： 用来访问业务接口，由于有效期足够短，盗用风险小，也可以使请求方式更宽松灵活；
• Refresh Token： 用来获取 Access Token，有效期可以长一些，通过独立服务和严格的请求方式增加安全性；由于不常验证，也可以如前面的 Session 一样处理；

Refresh Token 的认证流程图：



Refresh Token 认证步骤解析：

• 客户端： 输入用户名和密码请求登录校验；

• 服务端： 收到请求，验证用户名与密码；验证成功后，服务端会签发一个 Access Token 和 Refresh Token 并返回给客户端；

• 客户端： 把 Access Token 和 Refresh Token 存储在本地；

• 客户端发送请求： 请求数据时，携带 Access Token 传输给服务端；

• 服务端：

  • 验证 Access 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 的升级改良版。

• 存储地不同： Session 一般是存储在服务端；Token 是无状态的，一般由前端存储；
• 安全性不同： Session 和 Token 并不矛盾，作为身份认证 Token 安全性比 Session 好，因为每一个请求都有签名还能防止监听以及重放攻击；
• 支持性不同： Session-Cookie 认证需要靠浏览器的 Cookie 机制实现，如果遇到原生 NativeAPP 时这种机制就不起作用了，或是浏览器的 Cookie 存储功能被禁用，也是无法使用该认证机制实现鉴权的；而 Token 验证机制丰富了客户端类型。

如果你的用户数据可能需要和第三方共享，或者允许第三方调用 API 接口，用 Token 。如果永远只是自己的网站，自己的 App，用什么就无所谓了。

4. JWT（JSON Web Token）鉴权

---

通过第三节，我们知道了 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 中通常包含了两部分：

• typ：代表 Token 的类型，这里使用的是 JWT 类型；
• alg：使用的 Hash 算法，例如 HMAC SHA256 或 RSA.

 {
   "alg": "HS256",
   "typ": "JWT"
 }

Payload 负载：

它包含一些声明 Claim (实体的描述，通常是一个 User 信息，还包括一些其他的元数据) ，用来存放实际需要传递的数据，JWT 规定了7个官方字段：

• iss (issuer)：签发人
• exp (expiration time)：过期时间
• sub (subject)：主题
• aud (audience)：受众
• nbf (Not Before)：生效时间
• iat (Issued At)：签发时间
• jti (JWT ID)：编号

除了官方字段，你还可以在这个部分定义私有字段，下面就是一个例子。

 {
   "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 的优点

• 不需要在服务端保存会话信息（RESTful API 的原则之一就是无状态），所以易于应用的扩展，即信息不保存在服务端，不会存在 Session 扩展不方便的情况；
• JWT 中的 Payload 负载可以存储常用信息，用于信息交换，有效地使用 JWT，可以降低服务端查询数据库的次数

4.6 JWT 的缺点

• 加密问题： JWT 默认是不加密，但也是可以加密的。生成原始 Token 以后，可以用密钥再加密一次。
• 到期问题： 由于服务器不保存 Session 状态，因此无法在使用过程中废止某个 Token，或者更改 Token 的权限。也就是说，一旦 JWT 签发了，在到期之前就会始终有效，除非服务器部署额外的逻辑。

4.7 前端常用的 JWT 库推荐

• 使用 express：express-jwt
• 使用 koa：koa-jwt

5. 单点登录（Single Sign On）

---

前面我们已经知道了，在同域下的客户端/服务端认证系统中，通过客户端携带凭证，可以维持一段时间内的登录状态。

但随着企业的发展，一个大型系统里可能包含 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 🎜>未登录

  Pelanggan:
Masukkan nama pengguna dan kata laluan untuk pengesahan sistem CAS 🎜>
• Perkhidmatan pengesahan 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:
www.taobao.com?token=ST-345678)

• 生成 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 🎜>

Di sini pelanggan boleh berinteraksi dengan gembira dengan Sistem A~
Pelanggan:

Mula mengakses sistem B;

Sistem B:
• Ditemui Pengguna tidak log masuk, diubah hala ke perkhidmatan pengesahan SSO dan menghantar alamatnya sendiri sebagai parameter, dan melampirkan nilai kuki di bawah domain sso.com iaitu TGC yang dijana dalam langkah kelima;

Perkhidmatan Pengesahan CAS:
• Pusat Perkhidmatan Pengesahan CAS mendapati bahawa pengguna mempunyai log masuk, melompat kembali ke alamat Sistem B, dan melampirkan tiket (ST);

Sistem B:
• Dapatkan tiket (ST) dan pergi ke perkhidmatan pengesahan CAS untuk mengesahkan kesahihan tiket (ST). Selepas pengesahan berjaya, pelanggan juga boleh berinteraksi dengan sistem B~

(PS: Rasanya agak kekok untuk berada di kedua-dua belah lorong~)

• Perkara yang perlu diperhatikan di bawah log masuk tunggal:

Seperti yang ditunjukkan dalam proses dalam rajah, kami mendapati bahawa

selepas pengeluaran

, 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;

CAS umumnya menyediakan empat antara muka:

• CAS 认证服务: antara muka log masuk, digunakan untuk log masuk ke perkhidmatan kebenaran pusat授权令牌 ST

: Antara muka log keluar, digunakan untuk log keluar daripada perkhidmatan kebenaran pusat

• : Digunakan untuk mengesahkan sama ada pengguna log masuk ke perkhidmatan kebenaran pusat
  • /login: Digunakan untuk membenarkan setiap Perkhidmatan mengesahkan sama ada pengguna telah log masuk ke perkhidmatan kebenaran pusat
  • /logout
  • Tiket yang dijana oleh CAS: /validate
  • /serviceValidateTGT (Ticket Grangting Ticket)
  : TGT dikeluarkan oleh CAS untuk pengguna
  Dengan TGT, pengguna boleh membuktikan bahawa mereka telah berjaya log masuk ke CAS.

• 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.
  • ST (Tiket Perkhidmatan) : ST ialah tiket yang dikeluarkan oleh CAS untuk pengguna mengakses Perkhidmatan tertentu. 登录票据
  6. OAuth 2.0
  Apabila kita sebenarnya melayari laman web, apabila kita log masuk, selain daripada memasukkan semasa Selain akaun tapak web dan kata laluan, kami juga mendapati bahawa anda boleh log masuk melalui QQ atau WeChat pihak ketiga, jadi bagaimana untuk melakukan ini, kita perlu bercakap tentang
  OAuth
.

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 数据。

   {    
     "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	❌	✅	❌	✅

Dikelaskan mengikut jenis pelanggan dan pemilik token akses:

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 Log masuk bersekutu dan log masuk dipercayai

<.>

---

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. 用户名密码式模式

Senario penggunaan paling klasik ialah penggunaan H5 yang dibenamkan dalam APP Apabila pengguna memasuki H5 terbenam daripada APP, kami berharap pengguna yang log masuk dalam APP boleh mengakses sumber terhad dalam H5. tanpa Log masuk pengguna perlu log masuk untuk mengakses.

Terdapat dua idea utama di sini Satu adalah untuk melampirkan token log masuk ke parameter URL apabila melompat ke halaman H5 yang dibenamkan secara asli protokol untuk mendapatkan status log masuk dalam aplikasi.

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 . 信任登录

Akaun log masuk dipercayai pihak ketiga yang biasa pada masa ini termasuk: akaun QQ Taobao, akaun Alipay, akaun Weibo, dsb.

Tidak sukar untuk mendapati bahawa OAtuth 2.0 sebenarnya adalah lambang log masuk amanah, kerana dengan OAuth log masuk kepercayaan kami dapat direalisasikan.

8 Log masuk unik

---

— Katakan sekarang pengurus produk membuat permintaan:

Saya mahu membolehkan pengguna log masuk hanya pada satu peranti . Pengguna dilarang log masuk berulang kali; !

8.1 Apakah log masuk unik

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;

• Ujung belakang menjana Token yang sepadan dan mengembalikannya kepada klien A, dan menyimpan status log masuk pada pelayan; Pelanggan A menyimpan Token, dan setiap permintaan membawa Token yang sepadan dalam pengepala

• Pengguna beroperasi pada klien B:

• Tiba-tiba Pengguna itu; memulakan operasi log masuk pada klien B. Kami akan mendapati bahawa langkah-langkahnya adalah hampir sama dengan operasi pada klien A; Kemudian hasilkan Token baharu yang sepadan; 🎜>

9.1 Apakah itu log masuk kod QR

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 dengan

  dan 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.

Jika terminal mudah alih tidak diimbas, kod QR akan tamat tempoh secara automatik selepas satu tempoh masa.

• Kod diimbas menunggu pengesahan:

  二维码的形式

Versi mudah alih:

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;

• Selepas mengimbas kod QR pada telefon bimbit, ia akan secara automatik Mendapatkan ID kod QR, dan menghantar baucar maklumat log masuk terminal mudah alih (Token) dan ID kod QR sebagai parameter kepada pelayan Pada masa ini, telefon bimbit mesti dilog masuk (prasyarat untuk menggunakan log masuk imbasan ialah aplikasi terminal mudah alih dilog masuk status, supaya status log masuk boleh dikongsi).

  Pelayan:

  Selepas menerima permintaan daripada telefon bimbit, ia akan mengaitkan

  Mengapa 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

Versi mudah alih:

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; :

• Selepas pengesahan bahagian pelayan selesai, status kod QR akan dikemas kini dan

  akan dijana untuk bahagian PC Selepas itu, pihak PC akan memegang Token ini untuk mengakses bahagian pelayan.

  临时 Token Bahagian PC:

• Undian menunjukkan bahawa status kod QR dilog masuk, dan Token yang dihasilkan akan diperolehi, dan log masuk adalah selesai. Akses seterusnya diselesaikan berdasarkan Token.

  10 Log masuk satu klik (terpakai untuk APP asli) 正式的 Token

10.1 Log masuk dengan akaun dan kata laluan

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:

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 Keupayaan Internet Mudah Alih

• Platform Terbuka Akaun Telekom-E-Selancar

• 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:

  • Alibaba-. Perkhidmatan Pengesahan Nombor
  • Chuanglan - Pengesahan Flash
  • Aurora - Pensijilan Aurora
  • mob - Segera Pengesahan

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.

Ringkasan

---

Setelah mempelajari dan memahami 10 kaedah pengesahan di atas, mari kita ringkaskan secara ringkas

• HTTP 基本认证Sesuai untuk rangkaian dalaman, atau rangkaian yang tidak mempunyai keperluan keselamatan yang sangat tinggi;
• dan 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
Sesuai untuk laman web yang perlu mendaftarkan pengguna dengan cepat; APP ;
• 单点登录
• Artikel ini diterbitkan semula daripada: https://juejin.cn/post/7129298214959710244OAuth 2.0
Pengarang: Master Yi
• 扫码登录
bahagian hadapan web一键登录)