[Zusammenfassungsfreigabe] 10 häufig verwendete Front-End- und Back-End-Authentifizierungsmethoden, damit Sie nicht länger verwirrt sind

Was ist Berechtigungskontrolle?

Welche Beziehung besteht zwischen Authentifizierung, Autorisierung, Authentifizierung und Berechtigungskontrolle?

• Verwenden Sie die Zugangskarte, um die Tür zu öffnen: Die vier Links Authentifizierung, Autorisierung, Authentifizierung und Berechtigungskontrolle sind integriert und erfolgen gleichzeitig im Handumdrehen.
• Anmeldung auf der Website des Benutzers: Wenn sich der Benutzer mit dem Benutzer anmeldet Name und Passwort, sowohl Authentifizierung als auch Autorisierung. Jeder Link wird gemeinsam abgeschlossen, und Authentifizierung und Berechtigungskontrolle erfolgen bei nachfolgenden Zugriffsanfragen, beispielsweise bei der Auswahl von Artikeln oder beim Bezahlen.

Hier ist eine kleine Frage, über die jeder nachdenken sollte: Welche Beziehung besteht zwischen Authentifizierung und Authentifizierung? Jeder ist herzlich eingeladen, im Kommentarbereich zu diskutieren

Nachdem wir die Beziehung zwischen ihnen verstanden haben, sollten wir über die Front-End-Authentifizierung sprechen? Und was sind die Unterschiede zwischen ihnen?

1. HTTP-Basisauthentifizierung

In HTTP ermöglicht Basic Access Authentication) dem Client (normalerweise einem Webbrowser) die Weitergabe. Der Benutzer gibt einen Benutzernamen und ein Passwort ein, um die Identität des Benutzers zu überprüfen.
基本认证方案（Basic Access Authentication) 是允许客户端（通常指的就是网页浏览器）在请求时，通过用户提供用户名和密码的方式，实现对用户身份的验证。

因为几乎所有的线上网站都不会走该认证方案，所以该方案大家了解即可

1.1 认证流程图

1.2 认证步骤解析

• 客户端(如浏览器)： 向服务器请求一个受限的列表数据或资源，例如字段如下

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

  Nach dem Login kopieren

• 服务器：客户端你好，这个资源在安全区 baidu.com 里，是受限资源，需要基本认证；

  并且向客户端返回 401 状态码（Unauthorized 未被授权的）以及附带提供了一个认证域 www-Authenticate: Basic realm=”baidu.com”要求进行身份验证；

  其中Basic 就是验证的模式，而 realm="baidu.com" 说明客户端需要输入这个安全域的用户名和密码，而不是其他域的

   HTTP/1.1 401 Unauthorized
   www-Authenticate: Basic realm= "baidu.com"

  Nach dem Login kopieren

• 客户端： 服务器，我已经携带了用户名和密码给你了，你看一下；（注：如客户端是浏览器，那么此时会自动弹出一个弹窗，让用户输入用户名和密码）；

  输入完用户名和密码后，则客户端将用户名及密码以 Base64 加密方式发送给服务器

  传送的格式如下 (其中 Basic 内容为：用户名:密码 的 ase64 形式)：

   GET /list/ HTTP/1.1 
   Authorization: Basic Ksid2FuZzp3YW5n==

  Nach dem Login kopieren

• 服务器： 客户端你好，我已经校验了Authorization 字段你的用户名和密码，是正确的，这是你要的资源。

   HTTP/1.1 200 OK
   ...

  Nach dem Login kopieren

1.3 优点

简单，基本所有流行的浏览器都支持

1.4 缺点

• 不安全：

  • 由于是基于 HTTP 传输，所以它在网络上几乎是裸奔的，虽然它使用了 Base64 来编码，但这个编码很容易就可以解码出来。
  • 即使认证内容无法被解码为原始的用户名和密码也是不安全的，恶意用户可以再获取了认证内容后使用其不断的享服务器发起请求，这就是所谓的重放攻击。

• 无法主动注销：

  • 由于 HTTP 协议没有提供机制清除浏览器中的 Basic 认证信息，除非标签页或浏览器关闭、或用户清除历史记录。

1.5 使用场景

内部网络，或者对安全要求不是很高的网络。

2. Session-Cookie 鉴权

Session-Cookie 认证是利用服务端的 Session（会话）和 浏览器（客户端） 的 Cookie 来实现的前后端通信认证模式。

在理解这句话之前我们先简单了解下 什么是 Cookie 以及 什么是 Session ？

2.1 什么是 Cookie

众所周知，HTTP 是无状态的协议（对于事务处理没有记忆能力，每次客户端和服务端会话完成时，服务端不会保存任何会话信息）；

所以为了让服务器区分不同的客户端，就必须主动的去维护一个状态，这个状态用于告知服务端前后两个请求是否来自同一浏览器。而这个状态可以通过 Cookie

Da fast alle Online-Websites dieses Zertifizierungsschema nicht verwenden, kann jeder das Schema verstehen

🎜🎜🎜Client (z. B. Browser): 🎜 Fordern Sie vom Server eingeschränkte Listendaten oder Ressourcen an. Die Felder lauten beispielsweise wie folgt🎜

 eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

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

 {
   "sub": "1234567890",
   "name": "John Doe",
   "admin": true
 }

 HMACSHA256(
   base64UrlEncode(header) + "." +
   base64UrlEncode(payload),
   secret)

🎜🎜🎜Unsicher: 🎜🎜🎜🎜Da es auf HTTP-Übertragung basiert, ist es im Netzwerk nahezu unsicher Obwohl Base64 zum Kodieren verwendet wird, kann diese Kodierung leicht dekodiert werden. 🎜🎜Auch wenn der Authentifizierungsinhalt nicht in den ursprünglichen Benutzernamen und das ursprüngliche Passwort entschlüsselt werden kann, ist es unsicher. Böswillige Benutzer können den Authentifizierungsinhalt abrufen und dann ihren ständigen Freigabeserver verwenden, um Anfragen zu initiieren. 🎜🎜🎜🎜🎜🎜Aktives Abmelden nicht möglich🎜: 🎜🎜🎜Da das HTTP-Protokoll keinen Mechanismus zum Löschen der Basisauthentifizierungsinformationen im Browser bietet, es sei denn, die Registerkarte oder der Browser wird geschlossen oder der Benutzer löscht den Verlauf. 🎜🎜🎜🎜🎜🎜1,5 Nutzungsszenarien🎜🎜🎜Internes Netzwerk oder ein Netzwerk, das keine sehr hohen Sicherheitsanforderungen hat. 🎜🎜🎜2. Session-Cookie-Authentifizierung 🎜🎜🎜🎜Session-Cookie Die Authentifizierung ist ein Authentifizierungsmodus für die Front-End- und Back-End-Kommunikation, der mithilfe der Sitzung (Sitzung) des Servers und des Cookies implementiert wird des Browsers (Client) .
🎜🎜Bevor wir diesen Satz verstehen, wollen wir uns kurz mit Was ist Cookie und Was ist Sitzung befassen. 🎜🎜🎜2.1 Was ist Cookie🎜🎜🎜Wie wir alle wissen, ist HTTP ein zustandsloses Protokoll (keine Speicherkapazität für Transaktionen). 🎜🎜Damit der Server zwischen verschiedenen Clients unterscheiden kann, muss er aktiv einen Status aufrechterhalten, der zur Information des Servers verwendet wird vorher und nachher Ob beide Anfragen vom selben Browser kommen. Dieser Zustand kann durch Cookie erreicht werden. 🎜🎜🎜Eigenschaften:🎜🎜
• Cookies werden auf der Client-Seite gespeichert und können nach Belieben manipuliert werden.
• Es gibt eine Größenbeschränkung, die maximale Größe beträgt 4 KB.
• Es gibt eine Mengenbeschränkung Browser erlauben im Allgemeinen nur das Speichern von 300 Cookies. Android und IOS unterstützen Cookies nicht gut. Cookies sind nicht domänenübergreifend, der First-Level-Domainname und der Second-Level-Domainname jedoch schon darf geteilt werden (abhängig von der Domäne)
• 2.2 Was ist eine Sitzung? Das abstrakte Konzept einer Sitzung ist eine Sitzung, die eine Abstraktion der Interaktion zwischen dem Benutzer und dem Server darstellt, um eine Unterbrechung zu realisieren /Fortsetzung des Vorgangs während des zustandslosen Protokollkommunikationsprozesses;

Konkret handelt es sich um die vom Server generierte Sitzungsstruktur, die auf verschiedene Weise gespeichert werden kann, z. B. in Speicher, Datenbank, Dateien usw. Große Websites verfügen im Allgemeinen über dedizierte Sitzungsservercluster Benutzersitzungen speichern; Prinzipischer Prozess:

Client:

Der Benutzer sendet zum ersten Mal eine Anfrage an den Server;

• Server:

  empfängt die Daten und erstellt automatisch eine bestimmte Sitzung/ Sitzungs-ID für den Benutzer, um den Benutzer zu identifizieren und den aktuellen Sitzungsprozess des Benutzers zu verfolgen;

• Server:

  Nachdem der Server es extrahiert hat, vergleicht er es mit der lokal gespeicherten Sitzungs-ID, um die Sitzung des spezifischen Benutzers zu finden und dann den Sitzungsstatus zu erhalten;

Die Kommunikation zwischen dem Client und dem Server ist jetzt zur zustandsbehafteten Kommunikation geworden;

• Die Sitzung wird auf dem Server gespeichert;
• Durch die servereigene Verschlüsselung wird das Protokoll ausgeführt; Der Unterschied zwischen

• Sicherheit:

  Cookie wird auf der Clientseite gespeichert und kann nach Belieben manipuliert werden, während Session auf der Serverseite gespeichert wird und nicht gefälscht werden kann, sodass Session sicherer ist

Verschiedene Arten von Zugriffswerten:

Cookie Unterstützt nur String-Daten. Die Sitzung kann jeden Datentyp speichern Die vom Cookie gespeicherte Größe darf 4 KB nicht überschreiten.

Bei diesem Anblick haben sich einige Schüler möglicherweise gefragt, ob Session-Cookie nur Session verwendet. Wird es im des Clients gespeichert? Cookie?
• Bingo
, das ist tatsächlich der Fall, werfen wir einen Blick unten

2.3 Sitzungs-Cookie-Authentifizierungsflussdiagramm

• 
• 2.4 Session-Cookie-Authentifizierungsschrittanalyse
• Benutzerdefiniert äh Kunde : Anmeldeinformationen Benutzername/Passwort an den Server senden, um eine Anmeldebestätigung anzufordern;

Server: Session-Cookie 是不是就是把 Session 存储在了客户端的 Cookie 中呢？

Bingo，的确是这样的，我们接着往下看

2.3 Session-Cookie 的认证流程图



2.4 Session-Cookie 认证步骤解析

• 客户端： 向服务器发送登录信息用户名/密码来请求登录校验；

• 服务器： 验证登录的信息，验证通过后自动创建 Session（将 Session 保存在内存中，也可以保存在 Redis 中），然后给这个 Session 生成一个唯一的标识字符串会话身份凭证 session_id(通常称为 sid)，并在响应头 Set-Cookie 中设置这个唯一标识符；

  注：可以使用签名对 sid 进行加密处理，服务端会根据对应的 secret 密钥进行解密 （非必须步骤）

• 客户端： 收到服务器的响应后会解析响应头，并自动将 sid 保存在本地 Cookie 中，浏览器在下次 HTTP 请求时请求头会自动附带上该域名下的 Cookie 信息；

• 服务器： 接收客户端请求时会去解析请求头 Cookie 中的 sid，然后根据这个 sid 去找服务端保存的该客户端的 sid Überprüfen Sie die Anmeldeinformationen und erstellen Sie automatisch eine Sitzung, nachdem Sie die Überprüfung bestanden haben (speichern Sie die Sitzung dann im Speicher oder in Redis). Generieren Sie für diese Sitzung eine eindeutige Identifikationszeichenfolge für Sitzungsidentitätsanmeldeinformationen session_id (normalerweise sid genannt) und fügen Sie sie in den Antwortheader ein Set-Cookie;

Hinweis: Sie können eine Signatur verwenden, um sid zu verschlüsseln, und der Server entschlüsselt sie basierend auf dem entsprechenden geheimen-Schlüssel (optionaler Schritt)

Client:

Nach Erhalt der Antwort vom Server wird der Antwortheader analysiert und sid automatisch im lokalen Cookie gespeichert. Der Browser verwendet beim Erstellen das nächste HTTP Bei einer Anfrage werden dem Anfrage-Header automatisch die Cookie-Informationen unter dem Domainnamen beigefügt.
• Server:
• Beim Empfang einer Client-Anfrage wird die sid im Anfrage-Header-Cookie analysiert , und verwenden Sie dann diesen sid. Suchen Sie den vom Server gespeicherten sid und stellen Sie dann fest, ob die Anfrage legal ist

2.5 Vorteile der Sitzung -Cookie

🎜🎜🎜Cookie ist einfach zu verwenden🎜🎜Sitzungsdaten werden auf der Serverseite gespeichert und sind einfacher zu verwalten, d Das Hinzufügen und Löschen der entsprechenden Sitzung ist einfach. Es sind nur Back-End-Vorgänge erforderlich. Das Front-End kann ohne Sinn betrieben werden. 2.6 Nachteile von Session-Cookies
• Verlässt sich auf Cookies. Sobald der Benutzer Cookies im Browser deaktiviert, geht GG Smecta verloren.
• Es sind sehr unsichere Daten für den Browser, was das Risiko eines Datendiebstahls erhöht (durch CSRF und andere Angriffe leicht angreifbar). );
• Die Sitzung wird auf dem Server gespeichert, was den Overhead des Servers erhöht.
• ist für die mobile Unterstützung nicht geeignet Nutzungsszenarien

Anwendbar für allgemein mittlere und große Websites (außer für mobile APP-Terminals); Da allgemeine Sitzungen zentral auf einem Speicherserver (z. B. Redis) gespeichert werden müssen, erhöht dies das Budget des Servers Wenn Ihr Budget nicht ausreicht, wählen Sie bitte sorgfältig aus.

• 2.8 Häufig verwendete Sitzungsbibliotheken im Frontend werden empfohlen

3. Token-Authentifizierung Wie wir wissen, verursachen einige Mängel von Session-Cookie große Probleme auf dem Server Speichern Sie es, und wir müssen die Frage der Verteilung berücksichtigen und sogar einen separaten Server dafür aktivieren. Gibt es einen besseren Weg?


Dann entstand Token
3.1 Was ist Token?
Token ist ein Token, der Kunde, wenn der Client auf den Server zugreift Nach bestandener Überprüfung stellt der Server ihm ein Token aus. Danach kann der Client mit dem Token auf den Server zugreifen und der Server muss nur noch die Gültigkeit des Tokens überprüfen.

In einem Satz: Die Ressourcenanmeldeinformationen, die beim Zugriff auf die Ressourcenschnittstelle (API) erforderlich sind.

---

Allgemeine Token-Zusammensetzung: Session-Cookie 的一些缺点，以及 Session 的维护给服务端造成很大困扰，我们必须找地方存放它，又要考虑分布式的问题，甚至要单独为了它启用一套 Redis 集群。那有没有更好的办法？


那 Token 就应运而生了

3.1 什么是 Token（令牌）

Token 是一个令牌，客户端访问服务器时，验证通过后服务端会为其签发一张令牌，之后，客户端就可以携带令牌访问服务器，服务端只需要验证令牌的有效性即可。

一句话概括；访问资源接口（API）时所需要的资源凭证

一般 Token 的组成：

uid (用户唯一的身份标识) + time (当前时间的时间戳) + sign (签名，Token 的前几位以哈希算法压缩成的一定长度的十六进制字符串)

Token 的认证流程图：



Token 认证步骤解析：

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

• 服务器： 收到请求，去验证用户名与密码；验证成功后，服务端会签发一个 Token 并把这个 Token 发送给客户端；

• 客户端： 收到 Token 以后需要把它存储起来，web 端一般会放在 localStorage 或 Cookie 中，移动端原生 APP 一般存储在本地缓存中；

• 客户端发送请求： 向服务端请求 API 资源的时候，将 Token 通过 HTTP 请求头 Authorization 字段或者其它方式发送给服务端；

• 服务器： 收到请求，然后去验证客户端请求里面带着的 Token ，如果验证成功，就向客户端返回请求的数据，否则拒绝返还（401）；

Token 的优点：

• 服务端无状态化、可扩展性好： Token 机制在服务端不需要存储会话（Session）信息，因为 Token 自身包含了其所标识用户的相关信息，这有利于在多个服务间共享用户状态
• 支持 APP 移动端设备；
• 安全性好： 有效避免 CSRF 攻击（因为不需要 Cookie）
• 支持跨程序调用： 因为 Cookie 是不允许跨域访问的，而 Token 则不存在这个问题

Token 的缺点：

• 配合： 需要前后端配合处理；
• 占带宽： 正常情况下比 sid 更大，消耗更多流量，挤占更多宽带
• 性能问题： 虽说验证 Token 时不用再去访问数据库或远程服务进行权限校验，但是需要对 Token 加解密等操作，所以会更耗性能；
• 有效期短： 为了避免 Token 被盗用，一般 Token 的有效期会设置的较短，所以就有了 Refresh Token；

3.2 什么是 Refresh Token（刷新 Token）

业务接口用来鉴权的 Token，我们称之为 Access Token。

为了安全，我们的 Access Token 有效期一般设置较短，以避免被盗用。但过短的有效期会造成 Access Token 经常过期，过期后怎么办呢？

一种办法是：刷新 Access Token

🎜🎜uid🎜 (eindeutige Identität des Benutzers) + 🎜time🎜 (Zeitpunkt der aktuellen Zeit). ) + 🎜Sign🎜 (Signatur, die ersten Ziffern des Tokens werden mithilfe eines Hash-Algorithmus in eine hexadezimale Zeichenfolge einer bestimmten Länge komprimiert) 🎜🎜🎜Ablaufdiagramm zur Token-Authentifizierung: 🎜🎜🎜🎜🎜🎜Token-Authentifizierungsschrittanalyse: 🎜🎜
🎜🎜🎜Client: 🎜 Benutzernamen und Passwort eingeben, um eine Anmeldebestätigung anzufordern; 🎜🎜🎜🎜🎜Server: 🎜 Anforderung zur Überprüfung von Benutzernamen und Passwort erhalten; Überprüfung erfolgreich. Anschließend gibt der Server eine aus Token und Senden des Tokens an den Client; 🎜🎜🎜🎜🎜Client: 🎜 Nach Erhalt des Tokens muss es im Allgemeinen im lokalen Speicher oder Cookie gespeichert werden, und auf der mobilen Seite wird es im Allgemeinen in der nativen APP gespeichert im lokalen Cache gespeichert; 🎜🎜🎜🎜🎜Der Client sendet eine Anfrage: 🎜 Beim Anfordern von API-Ressourcen vom Server wird das Token über das Autorisierungsfeld des HTTP-Anforderungsheaders oder auf andere Weise an den Server gesendet Server: 🎜 Empfangen Sie die Anfrage und überprüfen Sie dann das in der Client-Anfrage enthaltene Token. Wenn die Überprüfung erfolgreich ist, werden die angeforderten Daten an den Client zurückgegeben, andernfalls wird die Rückgabe abgelehnt (401); 🎜🎜🎜🎜🎜 Vorteile des Tokens: 🎜🎜🎜 🎜🎜Der Server ist zustandslos und skalierbar: 🎜Der Token-Mechanismus muss keine Sitzungsinformationen auf der Serverseite speichern, da das Token selbst Informationen enthält, die sich auf den von ihm identifizierten Benutzer beziehen, was der gemeinsamen Nutzung durch mehrere förderlich ist Dienste Benutzerstatus 🎜🎜🎜Unterstützt APP-Mobilgeräte; 🎜🎜🎜🎜Gute Sicherheit: 🎜 Vermeidet effektiv CSRF-Angriffe (da keine Cookies erforderlich sind) 🎜🎜🎜Unterstützt programmübergreifende Aufrufe: 🎜 Da Cookies keinen domänenübergreifenden Zugriff zulassen, und Token haben dieses Problem nicht🎜🎜🎜🎜Nachteile von Token: 🎜🎜🎜🎜🎜Zusammenarbeit: 🎜 Erfordert Front-End- und Back-End-Zusammenarbeit; 🎜🎜🎜Belegte Bandbreite: 🎜 Normalerweise größer als sid, Verbrauchen Sie mehr Datenverkehr und belegen Sie mehr Bandbreite wird mehr Leistung verbrauchen; 🎜🎜 🎜Kurze Gültigkeitsdauer: 🎜 Um zu verhindern, dass Token gestohlen werden, ist die Gültigkeitsdauer von Token im Allgemeinen kürzer eingestellt, daher gibt es Refresh Token; 🎜3.2 Was ist ein Aktualisierungstoken? 🎜🎜🎜Der Token, der für die Authentifizierung durch die Geschäftsschnittstelle verwendet wird, wir nennen ihn Zugriffstoken. 🎜🎜Aus Sicherheitsgründen ist die Gültigkeitsdauer unseres Access Token grundsätzlich kürzer eingestellt, um einen Diebstahl zu verhindern. Eine zu kurze Gültigkeitsdauer führt jedoch dazu, dass das Zugriffstoken häufig abläuft. Was soll ich nach Ablauf tun? 🎜🎜Eine Möglichkeit ist: Zugriffstoken aktualisieren, was für Benutzer sehr mühsam ist, sich erneut anzumelden, um ein neues Token zu erhalten 🎜;

另外一种办法是：再来一个 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（主域名不同）

Auf unseren gemeinsamen Shopping-Websites Tmall (tmall.com) und Taobao (taobao.com) müssen wir uns nur bei einem der Systeme anmelden, und das andere System meldet sich standardmäßig an, nachdem wir es geöffnet haben Das?

Dann gibt es noch den zentralen Autorisierungsdienst CAS (Central Authentication Service), also sprechen wir zunächst über den Prozess der CAS; CAS（Central Authentication Service）中央授权服务，那么我们先主要说下 CAS 的流程；

单点登录下的 CAS 认证流程图：

单点登录下的 CAS 认证步骤详解：

• 客户端： 开始访问系统 A；

• 系统 A： 发现用户未登录，重定向至 CAS 认证服务（sso.com），同时 URL 地址参数携带登录成功后回跳到系统 A 的页面链接（sso.com/login?redir…

• CAS 认证服务： 发现请求 Cookie 中没有携带登录的票据凭证（TGC），所以 CAS 认证服务判定用户处于 未登录 状态，重定向用户页面至 CAS 的登录界面，用户在 CAS 的登录页面上进行登录操作。

• 客户端： 输入用户名密码进行 CAS 系统认证；

• CAS 认证服务： 校验用户信息，并且 生成 TGC 放入自己的 Session 中，同时以 Set-Cookie 形式写入 Domain 为 sso.com 的域下 ；同时生成一个 授权令牌 ST (Service Ticket) ，然后重定向至系统 A 的地址，重定向的地址中包含生成的 ST（重定向地址：www.taobao.com?token=ST-345678）

• 系统 A： 拿着 ST 向 CAS 认证服务发送请求，CAS 认证服务验证票据 (ST) 的有效性。验证成功后，系统 A 知道用户已经在 CAS 登录了（其中的 ST 可以保存到 Cookie 或者本地中），系统 A 服务器使用该票据 (ST) 创建与用户的会话，称为局部会话，返回受保护资源；

到这里客户端就可以跟系统 A 愉快的交往啦 ~

• 客户端： 开始访问系统 B；

• 系统 B： 发现用户未登录，重定向至 SSO 认证服务，并将自己的地址作为参数传递，并附上在 sso.com 域下的 cookie 值是第五步生成的 TGC；

• CAS 认证服务： CAS 认证服务中心发现用户已登录，跳转回系统 B 的地址，并附上票据 (ST) ;

• 系统 B： 拿到票据 (ST)，去 CAS 认证服务验证票据 (ST) 的有效性。验证成功后，客户端也可以跟系统 B 交往了 ~

(PS：脚踏两只船，感觉有点渣呀 ~)

单点登录下需要注意的点：

• 如图中流程所示，我们发现 CAS 认证服务 在签发的 授权令牌 ST 后，直接重定向，这样其实是比较容易容易被窃取，那么我们需要在系统 A 或者系统 B 在向 CAS 验证成功 (如图中的第 14 步和第 11 步) 后，再生成另一个新的验证 Token 返回给客户端保存；

• CAS 一般提供四个接口：

  • /login：登录接口，用于登录到中央授权服务
  • /logout：登出接口，用于从中央授权服务中登出
  • /validate：用于验证用户是否登录中央授权服务
  • /serviceValidate：用于让各个 Service 验证用户是否登录中央授权服务

• CAS 生成的票据：

  • TGT（Ticket Grangting Ticket） ：TGT 是 CAS 为用户签发的 登录票据
  • CAS-Authentifizierung unter Single Sign-On Diagramm:
  
  • Detaillierte Erläuterung der CAS-Authentifizierungsschritte beim Single Sign-On:

Client: Starten Sie den Zugriff auf System A;

System A : Es wird festgestellt, dass der Benutzer nicht angemeldet ist und zum CAS-Authentifizierungsdienst (sso.com) weitergeleitet wird. Gleichzeitig enthält der URL-Adressparameter nach erfolgreicher Anmeldung den Seitenlink von System A (sso.com/login ?redir…

🎜An diesem Punkt kann der Client problemlos mit System A kommunizieren Client: 🎜 Zugriff auf System B starten; 🎜🎜🎜🎜🎜 System B: 🎜 Es wurde festgestellt, dass der Benutzer nicht angemeldet ist, zum SSO-Authentifizierungsdienst weitergeleitet und seine eigene Adresse als Parameter übergeben und den Cookie-Wert unter dem SSO angehängt .com-Domain ist der fünfte Schritt. Generierter TGC; 🎜🎜🎜🎜🎜CAS-Authentifizierungsdienst: 🎜 Das CAS-Authentifizierungsservice-Center stellt fest, dass sich der Benutzer angemeldet hat, springt zurück zur Adresse von System B und hängt das Ticket an (ST); 🎜🎜🎜🎜🎜System B: 🎜 Ticket erhalten (ST), zum CAS-Authentifizierungsdienst gehen, um die Gültigkeit des Tickets zu überprüfen (ST). Nach erfolgreicher Verifizierung kann der Kunde auch mit System B interagieren~🎜🎜🎜

🎜(PS: Es fühlt sich ein bisschen dreckig an, zwei Boote zu haben~)🎜

🎜🎜Dinge, die man bei Einzelzeichen beachten sollte- on Point: 🎜🎜

🎜🎜Wie im Prozess in der Abbildung gezeigt, haben wir festgestellt, dass der CAS-Authentifizierungsdienst direkt nach der Ausstellung des Authorization Token ST umgeleitet wurde, also Eigentlich ist es relativ leicht zu stehlen, daher müssen wir ein weiteres neues Verifizierungstoken generieren und es zur Speicherung an den Client zurücksenden, nachdem sich System A oder System B erfolgreich bei CAS authentifiziert haben (Schritte 14 und 11 in der Abbildung). CAS bietet im Allgemeinen vier Schnittstellen: 🎜
🎜/login: Anmeldeschnittstelle, die zum Anmelden beim zentralen Autorisierungsdienst verwendet wird 🎜🎜/logout: Abmeldeschnittstelle, verwendet um sich vom zentralen Autorisierungsdienst abzumelden🎜🎜/validate: wird verwendet, um zu überprüfen, ob sich der Benutzer beim zentralen Autorisierungsdienst angemeldet hat🎜🎜/serviceValidate: wird verwendet, um jeden zuzulassen Dienst zur Überprüfung, ob sich der Benutzer beim zentralen Autorisierungsdienst anmeldet🎜🎜🎜🎜🎜Von CAS generierte Tickets: 🎜
🎜🎜TGT (Ticket Grangting Ticket)🎜: TGT ist ein ausgestelltes Anmeldeticket Wenn Sie für den Benutzer eine CAS-Anmeldung durchführen und über ein TGT verfügen, kann der Benutzer nachweisen, dass er sich erfolgreich bei CAS angemeldet hat. 🎜🎜🎜TGC: Ticket Granting Cookie: 🎜 Der CAS-Server generiert TGT und fügt es in seine eigene Sitzung ein. TGC ist die eindeutige Kennung (SessionId) dieser Sitzung. Sie wird auf der Browserseite in Form eines Cookies platziert wird vom CAS-Server verwendet, um die Identität der Anmeldeinformationen des Benutzers zu klären. 🎜🎜🎜ST (Service-Ticket)🎜: ST ist ein von CAS ausgestelltes Ticket für Benutzer zum Zugriff auf einen Dienst. 🎜🎜🎜🎜🎜🎜6. OAuth 2.0🎜🎜🎜🎜Wenn wir die Website tatsächlich durchsuchen, stellen wir beim Anmelden zusätzlich zur Eingabe des Kontos und Passworts der aktuellen Website fest, dass wir uns auch über Drittanbieter anmelden können QQ oder WeChat, wie geht das? Reden wir über 🎜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

  Nach dem Login kopieren

  上面 URL 中，response_type 参数表示要求返回授权码（code），client_id 参数让 B 知道是谁在请求，redirect_uri 参数是 B 接受或拒绝请求后的跳转网址，scope 参数表示要求的授权范围（这里是只读）



• 授权服务器：

  授权服务网站 会要求用户登录，然后询问是否同意给予 A 网站授权。用户表示同意，这时授权服务网站 就会跳回 redirect_uri 参数指定的网址。跳转时，会传回一个授权码，就像下面这样。

  https://a.com/callback?code=AUTHORIZATION_CODE

  Nach dem Login kopieren

  上面 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

  Nach dem Login kopieren

  上面 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":{...}
   }

  Nach dem Login kopieren

  上面 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

  Nach dem Login kopieren

  上面 URL 中，response_type参数为token，表示要求直接返回令牌。

• 授权服务器：

  用户跳转到授权服务器，登录后同意给予 A 网站授权。这时，授权服务器就会跳回redirect_uri 参数指定的跳转网址，并且把令牌作为 URL 参数，传给 A 网站。

   https://a.com/callback#token=ACCESS_TOKEN

  Nach dem Login kopieren

  上面 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

  Nach dem Login kopieren

  上面 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

  Nach dem Login kopieren

  上面 URL 中，grant_type参数等于client_credentials表示采用凭证式，client_id和client_secret用来让授权服务器 确认 A 的身份。

• 授权服务器：

  授权服务器 验证通过以后，直接返回令牌。

注意：这种方式给出的令牌，是针对第三方应用的，而不是针对用户的，即有可能多个用户共享同一个令牌。

6.5 授权模式选型

按授权需要的多端情况：

模式	需要前端	需要后端	需要用户响应	需要客户端密钥
授权码模式 Authorization Code	✅	✅	✅	✅
隐式授权模式 Implicit Grant	✅	❌	✅	❌
密码授权模式 Password Grant	✅	✅	✅	✅
客户端授权模式 Client Credentials	❌	✅	❌	✅

Klassifizierung nach Clienttyp und Zugriffstokenbesitzer:



Das Obige erklärt hauptsächlich die Grundlogik von OAuth2.0 auf einfache Weise. Wenn Sie mehr im Detail wissen möchten, können Sie dies überprüfen Offizielle Dokumentation ist eine gemeinsame Anmeldung Verbundanmeldung bezieht sich auf einen Anmeldedienst, der mehrere Anmeldeinformationen gleichzeitig überprüft. Gleichzeitig kann er auch als Anmeldedienst verstanden werden, der Drittanbieter verwendet. Parteiausweise zur Überprüfung.

Laienhaft ausgedrückt:

Für zwei Websites A und B ist die Verwendung des Kontos und Passworts von Website B beim Anmelden bei Website A eine gemeinsame Anmeldung, oder die Verwendung des Kontos und Passworts von Website A beim Anmelden bei Website B auch ein gemeinsames Login. Dieses Konzept ähnelt tatsächlich der oben erwähnten OAuth2.0-Authentifizierungsmethode Benutzername-Passwort-Modus.

Das klassischste ist das Verwendungsszenario von eingebettetem H5 in APP. Wenn Benutzer über APP auf eingebettetes H5 zugreifen, hoffen wir, dass in APP angemeldete Benutzer auf eingeschränkte Ressourcen in H5 zugreifen können, während nicht angemeldete Benutzer keine Anmeldung benötigen zugreifen. Hier gibt es zwei Hauptideen: Die eine besteht darin, das Anmeldetoken an den URL-Parameter anzuhängen, wenn man nativ zur eingebetteten H5-Seite springt, um die Anwendung aktiv über das mit der nativen Anmeldung eingerichtete Protokoll abzurufen Status innerhalb. 7.2 Was ist eine vertrauenswürdige Anmeldung? Bei den Anmeldeinformationen handelt es sich um private Geräteinformationen. Der Benutzer muss zu diesem Zeitpunkt keine zusätzlichen Anmeldeinformationen angeben. Vertrauenswürdige Anmeldung bezieht sich auch auf die Verwendung einer relativ ausgereiften Benutzerbibliothek eines Drittanbieters, um Anmeldeinformationen zu überprüfen und sich bei der Website anzumelden, die Sie gerade besuchen.

Für Laien ausgedrückt:

---

Wenn Website A angemeldet ist, können Sie direkt zu Website B springen, ohne sich anzumelden, was Trust Login ist.

Zu den derzeit gängigen vertrauenswürdigen Anmeldekonten von Drittanbietern gehören: QQ Taobao-Konto, Alipay-Konto, Weibo-Konto usw. Es fällt uns nicht schwer herauszufinden, dass OAtuth 2.0 tatsächlich der Inbegriff des Vertrauens-Logins ist, denn mit OAuth kann unser Vertrauens-Login realisiert werden.


8. Einmalige Anmeldung

联合登录 指同时包含多种凭证校验的登录服务，同时，也可以理解为使用第三方凭证进行校验的登录服务。

通俗点讲： 对于两个网站 A 和 B，在登录 A 网站的时候用 B 网站的帐号密码，就是联合登录，或者登录 B 网站的时候使用 A 网站的帐号密码，也是联合登录。

这样的概念其实与上面所讲的 OAuth2.0 的 用户名密码式模式 认证方式类似。

最经典的莫过于 APP 内嵌 H5 的使用场景，当用户从 APP 进入内嵌的 H5 时，我们希望 APP 内已登录的用户能够访问到 H5 内受限的资源，而未登录的用户则需要登录后访问。

这里思路主要有两种，一种是原生跳转内嵌 H5 页面时，将登录态 Token 附加在 URL 参数上，另一种则是内嵌 H5 主动通过与原生客户端制定的协议获取应用内的登录状态。

7.2 什么是信任登录

信任登录 是指所有不需要用户主动参与的登录，例如建立在私有设备与用户之间的绑定关系，凭证就是私有设备的信息，此时不需要用户再提供额外的凭证。信任登录又指用第三方比较成熟的用户库来校验凭证，并登录当前访问的网站。

通俗点讲： 在 A 网站有登录状态的时候，可以直接跳转到 B 网站而不用登录，就是 信任登录

– Angenommen, der Produktmanager stellt jetzt eine Anfrage:

Ich möchte erkennen, dass sich Benutzer nur auf einem Gerät anmelden können und Benutzern die wiederholte Anmeldung verbieten

– Als Ausgezeichneter Programmierer. Natürlich stellen wir ihn zufrieden! !

---

8.1 Was ist eine eindeutige Anmeldung?


Die einmalige Anmeldung bedeutet, dass

das gleichzeitige Anmelden mehrerer Personen bei demselben Konto verhindert wird.

Um es einfach auszudrücken: Nachdem sich Konto A bei Computer A angemeldet hat und sich Konto A erneut über Computer B angemeldet hat, wird Computer A beim Aufrufen der Seite mit der Meldung „Erneut anmelden“ angezeigt und geht zur Anmeldung über. Seite 8.2 Ablaufdiagramm für die eindeutige Anmeldung Nummer zum Anfordern der Login-Schnittstelle;

Das Backend generiert den entsprechenden Token und gibt ihn an Client A zurück und speichert einen Anmeldestatus auf dem Server;

Client A speichert den Token und jede Anfrage trägt den entsprechenden Token im Header;

Benutzervorgang auf Client B:

Plötzlich startet der Benutzer den Anmeldevorgang auf Client B. Wir werden feststellen, dass die Schritte fast die gleichen sind wie der Vorgang auf Client A; Es ist nur so, dass das Backend eine neue generiert Token, Sie müssen zuerst den Anmeldestatus überprüfen und dann den entsprechenden neuen Token generieren

9

Die Funktion „QR-Code-Anmeldung scannen“ ist normalerweise in mobilen Apps verfügbar. Es ist nicht erforderlich, auf der Webseite eine Kontonummer und ein Passwort einzugeben (z. B. WeChat, Taobao, QQ usw.) Die Möglichkeit für angemeldete Benutzer, QR-Code aktiv zu scannen und dann die Anmeldung zu bestätigen, damit sich dieselbe Anwendung auf dem PC schnell anmelden kann, ist scan Code-Anmeldung. 二维码 ，再确认登录，以使 PC 端的同款应用得以快速登录的方式就是 扫码登录 。

9.2 什么是二维码

二维码 又称二维条码，常见的二维码为 QR Code，QR 全称 Quick Response，是一个近几年来移动设备上超流行的一种编码方式，它比传统的Bar Code条形码能存更多的信息，也能表示更多的数据类型。

通过上面所述，我们不难发现，扫码登录需要三端 (PC端、手机端、服务端) 来进行配合才能达到登录成功的效果；

9.3 扫码登录的认证流程图



9.4 扫码登录的步骤详解 (待扫码阶段、待确认阶段、已确认阶段)

待扫码阶段：

• PC端：

  打开某个网站 (如taobao.com) 或者某个 APP (如微信) 的扫码登录入口；就会携带 PC 端的设备信息向服务端发送一个获取二维码的请求；

• 服务端：

  服务器收到请求后，随机生成一个 UUID 作为二维码 ID，并将 UUID 与 PC 端的设备信息 关联起来存储在 Redis 服务器中，然后返回给 PC 端；同时设置一个过期时间，在过期后，用户登录二维码需要进行刷新重新获取。

• PC 端：

  收到二维码 ID 之后，将二维码 ID 以 二维码的形式 展示，等待移动端扫码。并且此时的 PC 端开始轮询查询二维码状态，直到登录成功。

  如果移动端未扫描，那么一段时间后二维码会自动失效。

已扫码待确认阶段：

• 手机端：

  打开手机端对应已登录的 APP (微信或淘宝等)，开始扫描识别 PC 端展示的二维码；

  移动端扫描二维码后，会自动获取到二维码 ID，并将移动端登录的信息凭证（Token）和二维码 ID 作为参数发送给服务端，此时手机必须是已登录（使用扫描登录的前提是移动端的应用为已登录状态，这样才可以共享登录态）。

• 服务端：

  收到手机端发来的请求后，会将 Token 与二维码 ID 关联，为什么需要关联呢？因为，当我们在使用微信时，移动端退出时，PC 端也应该随之退出登录，这个关联就起到这个作用。然后会生成一个临时 Token，这个 Token 会返回给移动端，一次性 Token 用作确认时的凭证。

已确认阶段：

• 手机端：

  收到确认信息后，点击确认按钮，移动端携带上一步中获取的 临时 Token 发送给服务端校验；

• 服务端：

  服务端校验完成后，会更新二维码状态，并且给 PC 端生成一个 正式的 Token

• 9.2 Was ist ein QR-Code?
  QR-Code Der gebräuchliche QR-Code ist „Quick Response“. Ein mobiler Code, der in den letzten Jahren entwickelt wurde. Er ist eine sehr beliebte Codierungsmethode auf Geräten und kann mehr Informationen speichern und mehr Datentypen darstellen als der herkömmliche Barcode.
  Anhand des oben Gesagten können wir leicht feststellen, dass für das Scannen des QR-Codes zum Anmelden drei Terminals erforderlich sind (PC-Terminal, Mobiles Terminal, Server-Terminal). >). Für eine erfolgreiche Anmeldung ist Kooperation erforderlich /959/138/ 166124867037607[Zusammenfassungsfreigabe] 10 häufig verwendete Front-End- und Back-End-Authentifizierungsmethoden, damit Sie nicht länger verwirrt sind" title="166124867037607[Zusammenfassungsfreigabe] 10 häufig verwendete Front-End- und Back-End-Authentifizierungsmethoden, damit Sie nicht länger verwirrt sind" alt="1[Zusammenfassungsfreigabe] 10 häufig verwendete Front-End- und Back-End-Authentifizierungsmethoden, damit Sie nicht länger verwirrt sind"/>

9.4 Detaillierte Erläuterung der Schritte zum Anmelden durch Scannen des QR-Codes (die zu scannende Stufe, die zu bestätigende Phase, die bestätigte Phase)

Zu scannende Phase:

---

PC-Seite: Öffnen Sie das Scancode-Anmeldeportal einer Website (z. B. taobao.com). ) oder eine APP (z. B. WeChat); die Geräteinformationen des PCs werden an den Dienst gesendet. Der Client sendet eine Anfrage zum Abrufen des QR-Codes


Server:

Nach Erhalt der Anfrage sendet der Server Generiert zufällig eine UUID als QR-Code-ID und vergleicht die UUID mit PC-seitigen Geräteinformationen code>, ordnet sie zu und speichert sie auf dem Redis-Server und gibt sie dann gleichzeitig mit einer Ablaufzeit an den PC zurück festgelegt ist. Nach Ablauf muss der Anmelde-QR-Code des Benutzers aktualisiert und erneut abgerufen werden.

• PC-Terminal:

• Nach Erhalt der QR-Code-ID zeigen Sie die QR-Code-ID in Form von QR-code an und warten Sie, bis das mobile Terminal den Code scannt. Und zu diesem Zeitpunkt beginnt der PC mit der Abfrage des QR-Code-Status, bis die Anmeldung erfolgreich ist.
  Wenn das mobile Endgerät nicht gescannt wird, verfällt der QR-Code nach einiger Zeit automatisch.

Gescannter Code wartet auf Bestätigung:

🎜🎜🎜🎜🎜Mobile Version: 🎜🎜🎜Öffnen Sie die APP (WeChat oder Taobao usw.), die 🎜angemeldet🎜 entspricht, auf dem Mobiltelefon und beginnen Sie mit dem Scannen und Identifizieren des 2D QR-Code wird auf dem PC-Code angezeigt. 🎜🎜Nachdem das mobile Terminal den QR-Code gescannt hat, erhält es automatisch die QR-Code-ID und sendet den Anmeldeinformationsbeleg (Token) und die QR-Code-ID des mobilen Terminals als Parameter an den Server Diesmal muss das Mobiltelefon angemeldet sein (Voraussetzung für die Verwendung des Scan-Logins ist, dass die mobile Anwendung angemeldet ist, damit der Anmeldestatus geteilt werden kann). 🎜🎜🎜🎜🎜Server: 🎜🎜🎜Nach Erhalt der Anfrage vom Mobiltelefon wird das Token mit der QR-Code-ID verknüpft. Warum muss es verknüpft werden? Denn wenn wir WeChat verwenden und uns auf dem mobilen Endgerät abmelden, sollte sich auch das PC-Terminal abmelden. Diese Zuordnung spielt diese Rolle. Anschließend wird ein temporärer Token generiert, der an das mobile Endgerät zurückgegeben wird und der einmalige Token als Gutschein zur Bestätigung verwendet wird. 🎜🎜🎜🎜🎜 Bestätigte Phase: 🎜🎜🎜🎜🎜🎜Mobiles Endgerät: 🎜🎜🎜Nach Erhalt der Bestätigungsnachricht klicken Sie auf die Bestätigungsschaltfläche und das mobile Endgerät trägt den in der erhaltenen Temporären Token vorheriger Schritt und senden Sie es an die serverseitige Überprüfung; 🎜🎜🎜🎜🎜Serverseitig: 🎜🎜🎜Nachdem die serverseitige Überprüfung abgeschlossen ist, wird der QR-Code-Status aktualisiert und ein formeller Token wird für die nachfolgende PC-Seite generiert. Halten Sie einfach dieses Token gedrückt, um auf den Server zuzugreifen. 🎜🎜🎜🎜🎜PC-Seite: 🎜🎜🎜Der abgefragte QR-Code-Status wird angemeldet und der generierte Token wird abgerufen, die Anmeldung wird abgeschlossen und nachfolgende Besuche werden basierend auf dem Token abgeschlossen. 10. Ein-Klick-Anmeldung (gilt für native APP) zu Verwenden Sie 🎜Konto. Melden Sie sich mit einem Passwort an 🎜, es ist einfach und grob, und im Allgemeinen gibt es keine Probleme 🎜🎜🎜Nachteile: 🎜🎜🎜🎜🎜Aber diese Methode erfordert, dass sich Benutzer ihre Kontonummer und ihr Passwort merken, was bedeutet, dass sie vorhanden sind ist ein Speicheraufwand. Um die Speicherkosten zu senken, verwenden Benutzer wahrscheinlich die gleichen Kontokennwörter auf verschiedenen Plattformen. Aus Sicherheitsgründen sind andere vom Benutzer verwendete Plattformen betroffen, sobald das Kontokennwort einer bestimmten Plattform durchgesickert ist. 🎜🎜🎜🎜Da das Konto außerdem nichts mit der persönlichen Identität zu tun hat, bedeutet dies, dass derselbe Benutzer mehrere verschiedene Konten registrieren kann, was bedeutet, dass eine böswillige Registrierung erfolgen kann. 🎜🎜🎜🎜🎜Bis das obligatorische Echtnamensystem für Handykarten gelöst ist! 🎜🎜

10.2 Anmeldung mit dem Bestätigungscode für die Mobiltelefonnummer

Mit der Entwicklung des drahtlosen Internets und der Förderung des Echtnamensystems für Mobiltelefonkarten ist die Mobiltelefonnummer im Vergleich zum Kontopasswort und zum Mobiltelefon zu einem besonderen Identitätsnachweis geworden Die Nummer kann die Benutzeridentität besser überprüfen, um eine böswillige Registrierung zu verhindern.

Die Registrierung einer Mobiltelefonnummer erfordert jedoch immer noch eine Reihe langwieriger Vorgänge: Geben Sie die Mobiltelefonnummer ein, warten Sie auf den SMS-Bestätigungscode, geben Sie den Bestätigungscode ein und klicken Sie, um sich anzumelden. Der gesamte Vorgang dauert mindestens zwanzig Sekunden. Wenn Sie die Textnachricht nicht erhalten, müssen Sie sich anmelden, um dies auszugleichen. Ein solches Problem kann zu potenziellen Benutzerverlusten führen.

Aus Sicherheitsgründen besteht auch das Risiko, dass der Verifizierungscode durchsickert. Wenn jemand Ihre Handynummer kennt und den Verifizierungscode stiehlt, kann er sich auch in Ihr Konto einloggen.

Es gibt also einen Ein-Klick-Anmeldevorgang!

10.3 Was ist One-Click-Login?

Lassen Sie uns darüber nachdenken: Warum brauchen wir einen Bestätigungscode? Die Funktion des Bestätigungscodes besteht darin, zu bestätigen, dass die Mobiltelefonnummer Ihnen gehört. Gibt es neben der Verwendung von Textnachrichten eine andere Möglichkeit, die Mobiltelefonnummer zu authentifizieren?

So kann sich unser Protagonist mit einem Klick anmelden.

Die Funktion des SMS-Bestätigungscodes besteht darin, zu beweisen, dass der Benutzer der aktuellen Betriebsseite und der Benutzer, der die Mobiltelefonnummer eingegeben hat, tatsächlich dieselbe Person sind, solange wir die von ihm verwendete Mobiltelefonkartennummer erhalten können Mit dem aktuellen Mobiltelefon können wir uns direkt mit dieser Nummer anmelden, ohne zusätzliche Kosten. Der Vorgang ist Ein-Klick-Anmeldung.

Ob eine Ein-Klick-Anmeldung möglich ist, hängt davon ab, ob der Betreiber zugehörige Dienste öffnet. Da der Betreiber zugehörige Dienste öffnet, können wir jetzt auf das vom Betreiber bereitgestellte SDK zugreifen und für die Nutzung zugehöriger Dienste bezahlen.

Ein-Klick-Anmeldeflussdiagramm:



Detaillierte Erläuterung der Ein-Klick-Anmeldeschritte:

• SDK-Initialisierung: Rufen Sie die SDK-Methode auf und übergeben Sie den von der konfigurierten AppKey und AppSecret Plattform

• Arouse-Autorisierungsseite: Rufen Sie das SDK auf, um die Autorisierungsschnittstelle aufzurufen. Das SDK initiiert zunächst eine Anfrage an den Betreiber, um die Mobiltelefonnummernmaske zu erhalten, und springt dann zur Autorisierung Seite. Auf der Autorisierungsseite werden zur Benutzerbestätigung die Mobiltelefonnummernmaske und die Betreibervereinbarung angezeigt.

• Der Autorisierung zustimmen und sich anmelden: Der Benutzer stimmt der entsprechenden Vereinbarung zu und klickt auf die Anmeldeschaltfläche auf der Autorisierungsseite. Nachdem die Anfrage erfolgreich war, wird der Token angefordert an den Client zurückgegeben werden

• Nummer abrufen: Senden Sie das erhaltene Token an Ihren eigenen Server, und der Server überträgt das Token und ruft die Ein-Klick-Anmeldeschnittstelle des Betreibers auf. Wenn der Anruf erfolgreich ist, wird das Mobiltelefon aufgerufen Nummer wird zurückgegeben. Der Server verwendet die Mobiltelefonnummer zum Anmelden oder Registrieren und gibt die Vorgangsergebnisse an den Client zurück, um die Anmeldung mit einem Klick abzuschließen.

Drei große Betreiber öffnen Plattformen:

• Mobilfunk – offene Plattform für Internetfähigkeit

• Telekom – offene Plattform für Tianyi-Konto

• China Unicom – WO+ offene Plattform

  Da die drei großen inländischen Betreiber jeweils über unabhängige SDKs verfügen, wird die Kompatibilitätsarbeit besonders umständlich sein. Wenn Sie eine Ein-Klick-Anmeldelösung verwenden möchten, möchten Sie möglicherweise einen Drittanbieter mit der Bereitstellung von Nummernauthentifizierungsdiensten beauftragen. Die folgenden Anbieter verfügen alle über Funktionen zur Authentifizierung von Mobiltelefonnummern:

  • Alibaba-Number Authentication Service
  • Chuanglan-Flash-Verifizierung
  • Aurora – Aurora-Zertifizierung
  • mob – Zweite Verifizierung

Hinweis:

Während des Authentifizierungsprozesses muss der Benutzer das Mobilfunknetz einschalten Im Mobiltelefon ist keine SIM-Karte eingelegt oder das Mobilfunknetz ist ausgeschaltet. In diesem Fall kann die Authentifizierung nicht abgeschlossen werden. Selbst wenn die Ein-Klick-Anmeldung aktiviert ist, muss sie daher dennoch mit herkömmlichen Anmeldemethoden kompatibel sein, damit Benutzer den Anmeldevorgang im Falle eines Fehlers weiterhin normal abschließen können.

Zusammenfassung

---

Nachdem wir die oben genannten 10 Authentifizierungsmethoden kennengelernt und verstanden haben, fassen wir kurz zusammen


• HTTP Basic Authentication eignet sich für interne Netzwerke oder Netzwerke, die keine sehr hohen Sicherheitsanforderungen haben. HTTP 基本认证适用于内部网络，或者对安全要求不是很高的网络；
• Session-Cookie 适用于一般中大型的网站（移动端 APP 除外）；
• Token 和 JWT 都适用于市面上大部分的企业型网站，JWT 效能会优于 Token；
• 单点登录 适用于子系统较多的大型企业网站；
• OAuth 2.0适用于需要快速注册用户型的网站；
• 扫码登录 适用于已完成部署了三端的企业；
• 一键登录
Session-Cookie eignet sich für allgemeine mittlere und große Websites ( mobile APPs Außer);

Token und JWT sind für die meisten Unternehmenswebsites auf dem Markt geeignet, und die JWT-Leistung ist besser als Token

Single Sign -On eignet sich für große Unternehmenswebsites mit vielen Subsystemen; <p></p> <code>OAuth 2.0 eignet sich für Websites, die Benutzer schnell registrieren müssen;

QR-Code scannen, um sich anzumelden ist für bestehende Benutzer geeignet. Unternehmen, die die Bereitstellung von drei Terminals abgeschlossen haben. <a href="//m.sbmmt.com/course/list/1.html" target="_blank" textvalue="web前端"></a><code>Ein-Klick-Anmeldung ist für native APP geeignet. /juejin.cn/post/7129298214959710244

🎜Autor: Master Yi🎜 🎜🎜 (Lernvideo-Sharing: 🎜Web-Frontend🎜)🎜