Was bedeuten Token, Cookie, Sitzung, JWT, Single Sign-On, Scan-Code-Anmeldung und One-Click-Anmeldung in Bezug auf die Front-End-Authentifizierung? Welche Funktionen haben sie jeweils? Wie machst du das normalerweise? Und wie lagert man es? Wie schützt man es also? Im folgenden Artikel erfahren Sie, wie Sie mit allen Authentifizierungsschemata im Front- und Backend umgehen, damit Sie nicht länger verwirrt werden!
Ich erinnere mich noch daran, dass ein Interviewer während des Interviews in Bezug auf die Front-End-Authentifizierung fragte: Was sind Token, Cookie, Session, JWT und Single Sign-On? Was macht es? Wie machst du das normalerweise? Und wie lagert man es? Wie schützen Sie es? Token、Cookie、Session、JWT、单点登录是什么？有什么作用？你一般是怎么做的？以及你是怎么存储的呢？那你又是怎么保证 它 的安全的呢？
一顿连问下来，我是焦头又烂额，欲言而又止.......
其实鉴权的方法有很多，下面我总结了常用的 10种鉴权方法，那么哪一种是最适合你的系统呢？哪一种又最安全呢？
那就让我们从下文慢慢探索寻找答案吧 ~
在介绍鉴权方法之前，我们先要了解的是：什么是认证、授权、鉴权、权限控制以及他们之间的关系，有了他们做铺垫，那么我们才能做到从始至终的了解透彻 ~
认证(Identification) 是指根据声明者所特有的识别信息，确认声明者的身份。
白话文的意思就是：你需要用身份证证明你自己是你自己。
比如我们常见的认证技术：
授权(Authorization)： 在信息安全领域是指资源所有者委派执行者，赋予执行者指定范围的资源操作权限，以便对资源的相关操作。
在现实生活领域例如： 银行卡（由银行派发）、门禁卡（由物业管理处派发）、钥匙（由房东派发），这些都是现实生活中授权的实现方式。
在互联网领域例如： web 服务器的 session 机制、web 浏览器的 cookie 机制、颁发授权令牌（token）等都是一个授权的机制。
鉴权(Authentication) 在信息安全领域是指对于一个声明者所声明的身份权利，对其所声明的真实性进行鉴别确认的过程。
若从授权出发，则会更加容易理解鉴权。授权和鉴权是两个上下游相匹配的关系，先授权，后鉴权。
在现实生活领域： 门禁卡需要通过门禁卡识别器，银行卡需要通过银行卡识别器；
在互联网领域： 校验 session/cookie/token 的合法性和有效性
鉴权 是一个承上启下的一个环节，上游它接受授权的输出，校验其真实性后，然后获取权限（permission），这个将会为下一步的权限控制做好准备。
权限控制(Access/Permission Control) 将可执行的操作定义为权限列表，然后判断操作是否允许/禁止
对于权限控制，可以分为两部分进行理解：一个是权限，另一个是控制。权限是抽象的逻辑概念，而控制是具体的实现方式。
在现实生活领域中： 以门禁卡的权限实现为例，一个门禁卡，拥有开公司所有的门的权限；一个门禁卡，拥有管理员角色的权限，因而可以开公司所有的门。
在互联网领域： 通过 web 后端服务，来控制接口访问，允许或拒绝访问请求。
看到这里，我们应该明白了认证、授权、鉴权和权限控制这四个环节是一个前后依次发生、上下游
![[Zusammenfassungsfreigabe] 10 häufig verwendete Front-End- und Back-End-Authentifizierungsmethoden, damit Sie nicht länger verwirrt sind](https://img.php.cn/upload/image/935/458/926/166124857181896%5BZusammenfassungsfreigabe%5D%2010%20h%C3%A4ufig%20verwendete%20Front-End-%20und%20Back-End-Authentifizierungsmethoden,%20damit%20Sie%20nicht%20l%C3%A4nger%20verwirrt%20sind "166124857181896[Zusammenfassungsfreigabe] 10 häufig verwendete Front-End- und Back-End-Authentifizierungsmethoden, damit Sie nicht länger verwirrt sind")
10 Authentifizierungsmethoden. Welche ist also für Ihr System am besten geeignet? Welches ist das sicherste?
Dann lassen Sie uns langsam die Antwort aus dem Folgenden erforschen und finden ~
🎜🎜Bevor wir die Authentifizierungsmethode einführen, müssen wir zunächst Folgendes verstehen: 
Was sind Authentifizierung, Autorisierung, Authentifizierung, Berechtigungskontrolle und die Beziehung zwischen ihnen, mit ihnen als Grundlage, dann können wir von Anfang bis Ende ein umfassendes Verständnis haben~🎜Authentifizierung (Identifizierung) bezieht sich auf die Bestätigung der Identität des Anmelders auf der Grundlage der eindeutigen Identifikationsinformationen des Anmelders. 🎜🎜Die Bedeutung im Volksmund ist: Sie müssen Ihren Personalausweis verwenden, um zu beweisen, dass Sie Sie selbst sind. 🎜🎜Zum Beispiel unsere gängigen Authentifizierungstechnologien: 🎜Autorisierung: Im Bereich der Informationssicherheit bezieht es sich auf den Ressourcenbesitzer, der den Ausführenden mit der Erteilung von Executor gibt eine Reihe von Ressourcenoperationsberechtigungen an, um verwandte Operationen an Ressourcen auszuführen. 🎜🎜Im realen Bereich zum Beispiel: Bankkarten (verteilt durch Banken), Zugangskarten (verteilt durch Hausverwaltungen), Schlüssel (verteilt durch Vermieter), das sind alles Möglichkeiten der Verwirklichung Autorisierung im wirklichen Leben. 🎜🎜Im Internetbereich zum Beispiel: Der Sitzungsmechanismus des Webservers, der Cookie-Mechanismus des Webbrowsers und die Ausstellung von Autorisierungstokens (Tokens) sind alles Autorisierungsmechanismen. 🎜Authentifizierung Im Bereich der Informationssicherheit bezieht es sich auf die Identifizierung und Bestätigung der Authentizität der von einem Anmelder erklärten Identitätsrechte von. 🎜🎜Wenn Sie mit der Autorisierung beginnen, ist es einfacher, die Authentifizierung zu verstehen. Autorisierung und Authentifizierung sind zwei übereinstimmende Upstream- und Downstream-Beziehungen. Zuerst Autorisierung, dann Authentifizierung. 🎜🎜Im realen Bereich: Zugangskontrollkarten müssen die Zugangskarten-ID weitergeben, und Bankkarten müssen die Bankkarten-ID weitergeben 🎜🎜Im Internet-Bereich: strong> Sitzung/Cookie überprüfen Die Rechtmäßigkeit und Gültigkeit von /token🎜🎜Authentication ist eine Verbindung zwischen der vorherigen und der nächsten. Der Upstream akzeptiert die autorisierte Ausgabe, überprüft ihre Authentizität und erhält dann die Erlaubnis wird auf den nächsten Schritt der Berechtigungskontrolle vorbereitet. 🎜Zugriffs-/Berechtigungskontrolle Definieren Sie ausführbare Vorgänge als Berechtigungsliste und bestimmen Sie dann, ob der Vorgang erlaubt/verboten ist🎜🎜Zur Berechtigungskontrolle kann er in Dort unterteilt werden Es sind zwei Teile zu verstehen: der eine sind Berechtigungen und der andere die Kontrolle. Erlaubnis ist ein abstraktes logisches Konzept, während Kontrolle eine konkrete Implementierungsmethode ist. 🎜🎜Im realen Leben: Nehmen Sie als Beispiel die Berechtigungsimplementierung von Zutrittskontrollkarten der Administratorrolle, sodass alle Unternehmenstüren geöffnet werden können. 🎜🎜Im Internetbereich: Kontrollieren Sie den Schnittstellenzugriff über Web-Backend-Dienste, indem Sie Zugriffsanfragen zulassen oder ablehnen. 🎜Authentifizierung, Autorisierung, Authentifizierung und Berechtigungskontrolleverstehen >Diese vier Links sind eine sequentielle Beziehung, Upstream und Downstream 🎜🎜🎜🎜🎜Es ist zu beachten, dass diese vier Links manchmal gleichzeitig auftreten. Beispielsweise in den folgenden Szenen: 🎜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?
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=
服务器：客户端你好，这个资源在安全区 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"
客户端： 服务器，我已经携带了用户名和密码给你了，你看一下；（注：如客户端是浏览器，那么此时会自动弹出一个弹窗，让用户输入用户名和密码）；
输入完用户名和密码后，则客户端将用户名及密码以 Base64 加密方式发送给服务器
传送的格式如下 (其中 Basic 内容为：用户名:密码 的 ase64 形式)：
GET /list/ HTTP/1.1 Authorization: Basic Ksid2FuZzp3YW5n==
服务器： 客户端你好，我已经校验了Authorization 字段你的用户名和密码，是正确的，这是你要的资源。
HTTP/1.1 200 OK ...
1.3 优点
简单，基本所有流行的浏览器都支持
1.4 缺点
不安全：
无法主动注销：
1.5 使用场景
内部网络，或者对安全要求不是很高的网络。
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
🎜1.1 Zertifizierungsablaufdiagramm 🎜 🎜🎜![[Zusammenfassungsfreigabe] 10 häufig verwendete Front-End- und Back-End-Authentifizierungsmethoden, damit Sie nicht länger verwirrt sind](https://img.php.cn/upload/image/566/383/335/166124857782138%5BZusammenfassungsfreigabe%5D%2010%20h%C3%A4ufig%20verwendete%20Front-End-%20und%20Back-End-Authentifizierungsmethoden,%20damit%20Sie%20nicht%20l%C3%A4nger%20verwirrt%20sind "166124857782138[Zusammenfassungsfreigabe] 10 häufig verwendete Front-End- und Back-End-Authentifizierungsmethoden, damit Sie nicht länger verwirrt sind")
🎜🎜🎜1.2 Analyse der Authentifizierungsschritte🎜🎜eingeschränkte Listendaten oder Ressourcen an. Die Felder lauten beispielsweise wie folgt🎜eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
baidu . com ist eine eingeschränkte Ressource, die eine Basisauthentifizierung erfordert 🎜🎜 und einen 401-Statuscode (Nicht autorisiert) an den Client zurückgibt und eine Authentifizierungsdomäne bereitstellt www-Authenticate: Basic realm =“baidu.com“ code> erfordert eine Authentifizierung; 🎜🎜wobei <code>Basic der Verifizierungsmodus ist und realm="baidu.com" angibt, dass der Client den Benutzernamen und das Passwort dieser Sicherheitsdomäne eingeben muss , nicht das 🎜 {
"alg": "HS256",
"typ": "JWT"
} {
"sub": "1234567890",
"name": "John Doe",
"admin": true
}Autorisierung überprüft. Das stimmt , das ist die gewünschte Ressource. 🎜HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)
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) . 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:🎜🎜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;
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;
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 Sitzung wird auf dem Server gespeichert;
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
Cookie Unterstützt nur String-Daten. Die Sitzung kann jeden Datentyp speichern Die vom Cookie gespeicherte Größe darf 4 KB nicht überschreiten.
Session-Cookie nur Session verwendet. Wird es im des Clients gespeichert? Cookie? 2.3 Sitzungs-Cookie-Authentifizierungsflussdiagramm
![[Zusammenfassungsfreigabe] 10 häufig verwendete Front-End- und Back-End-Authentifizierungsmethoden, damit Sie nicht länger verwirrt sind](https://img.php.cn%20/%20upload/image/192/758/195/166124858574844%5BZusammenfassungsfreigabe%5D%2010%20h%C3%A4ufig%20verwendete%20Front-End-%20und%20Back-End-Authentifizierungsmethoden,%20damit%20Sie%20nicht%20l%C3%A4nger%20verwirrt%20sind "166124858574844[Zusammenfassungsfreigabe] 10 häufig verwendete Front-End- und Back-End-Authentifizierungsmethoden, damit Sie nicht länger verwirrt sind")
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;
![[Zusammenfassungsfreigabe] 10 häufig verwendete Front-End- und Back-End-Authentifizierungsmethoden, damit Sie nicht länger verwirrt sind](https://img.php.cn/upload/image/192/758/195/166124858574844%5BZusammenfassungsfreigabe%5D%2010%20h%C3%A4ufig%20verwendete%20Front-End-%20und%20Back-End-Authentifizierungsmethoden,%20damit%20Sie%20nicht%20l%C3%A4nger%20verwirrt%20sind "166124858574844[Zusammenfassungsfreigabe] 10 häufig verwendete Front-End- und Back-End-Authentifizierungsmethoden, damit Sie nicht länger verwirrt sind")
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 undsid 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. 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-CookiesAnwendbar 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.
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?
TokenToken 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. 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 的缺点：
![[Zusammenfassungsfreigabe] 10 häufig verwendete Front-End- und Back-End-Authentifizierungsmethoden, damit Sie nicht länger verwirrt sind](https://img.php.cn/upload/image/864/554/486/166124859229896%5BZusammenfassungsfreigabe%5D%2010%20h%C3%A4ufig%20verwendete%20Front-End-%20und%20Back-End-Authentifizierungsmethoden,%20damit%20Sie%20nicht%20l%C3%A4nger%20verwirrt%20sind "166124859229896[Zusammenfassungsfreigabe] 10 häufig verwendete Front-End- und Back-End-Authentifizierungsmethoden, damit Sie nicht länger verwirrt sind")
sid 更大，消耗更多流量，挤占更多宽带Refresh Token；3.2 什么是 Refresh Token（刷新 Token）
业务接口用来鉴权的 Token，我们称之为 Access Token。
为了安全，我们的 Access Token 有效期一般设置较短，以避免被盗用。但过短的有效期会造成 Access Token 经常过期，过期后怎么办呢？
一种办法是：刷新 Access Token
![[Zusammenfassungsfreigabe] 10 häufig verwendete Front-End- und Back-End-Authentifizierungsmethoden, damit Sie nicht länger verwirrt sind](https:%20//img%20.php.cn/upload/image/864/554/486/166124859229896%5BZusammenfassungsfreigabe%5D%2010%20h%C3%A4ufig%20verwendete%20Front-End-%20und%20Back-End-Authentifizierungsmethoden,%20damit%20Sie%20nicht%20l%C3%A4nger%20verwirrt%20sind "166124859229896[Zusammenfassungsfreigabe] 10 häufig verwendete Front-End- und Back-End-Authentifizierungsmethoden, damit Sie nicht länger verwirrt sind")
🎜🎜🎜Token-Authentifizierungsschrittanalyse: 🎜🎜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；
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 中通常包含了两部分：
![[Zusammenfassungsfreigabe] 10 häufig verwendete Front-End- und Back-End-Authentifizierungsmethoden, damit Sie nicht länger verwirrt sind](https://img.php.cn/upload/image/724/427/748/166124859837135%5BZusammenfassungsfreigabe%5D%2010%20h%C3%A4ufig%20verwendete%20Front-End-%20und%20Back-End-Authentifizierungsmethoden,%20damit%20Sie%20nicht%20l%C3%A4nger%20verwirrt%20sind "166124859837135[Zusammenfassungsfreigabe] 10 häufig verwendete Front-End- und Back-End-Authentifizierungsmethoden, damit Sie nicht länger verwirrt sind")
{
"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（主域名不同）
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 一般提供四个接口：
![[Zusammenfassungsfreigabe] 10 häufig verwendete Front-End- und Back-End-Authentifizierungsmethoden, damit Sie nicht länger verwirrt sind](https://img.php.cn/upload/image/897/341/729/166124860695111%5BZusammenfassungsfreigabe%5D%2010%20h%C3%A4ufig%20verwendete%20Front-End-%20und%20Back-End-Authentifizierungsmethoden,%20damit%20Sie%20nicht%20l%C3%A4nger%20verwirrt%20sind "166124860695111[Zusammenfassungsfreigabe] 10 häufig verwendete Front-End- und Back-End-Authentifizierungsmethoden, damit Sie nicht länger verwirrt sind")
/login：登录接口，用于登录到中央授权服务/logout：登出接口，用于从中央授权服务中登出/validate：用于验证用户是否登录中央授权服务/serviceValidate：用于让各个 Service 验证用户是否登录中央授权服务CAS 生成的票据：
登录票据
![[Zusammenfassungsfreigabe] 10 häufig verwendete Front-End- und Back-End-Authentifizierungsmethoden, damit Sie nicht länger verwirrt sind](https://img.php.cn/upload/image/323/229/797/166124861395999%5BZusammenfassungsfreigabe%5D%2010%20h%C3%A4ufig%20verwendete%20Front-End-%20und%20Back-End-Authentifizierungsmethoden,%20damit%20Sie%20nicht%20l%C3%A4nger%20verwirrt%20sind "166124861395999[Zusammenfassungsfreigabe] 10 häufig verwendete Front-End- und Back-End-Authentifizierungsmethoden, damit Sie nicht länger verwirrt sind")
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…
Nicht angemeldet befand, und hat erneut versucht, die Benutzerseite auf die CAS-Anmeldeoberfläche umzuleiten, und der Benutzer meldet sich auf der CAS-Anmeldeseite an : 🎜 Geben Sie den Benutzernamen und das Passwort für die CAS-Systemauthentifizierung ein; 🎜🎜🎜🎜🎜CAS-Authentifizierungsdienst: 🎜 Verifizierung Benutzerinformationen, generieren Sie TGC und fügen Sie diese in Ihre eigene Sitzung ein und schreiben Sie sie in das Formular von Set-Cookie unter der Domain, deren Domain sso.com ist, generieren Sie gleichzeitig ein Autorisierungstoken ST (Service Ticket) und leiten Sie es dann an die Adresse von weiter System A. Die umgeleitete Adresse enthält die generierte ST (Umleitungsadresse: www.taobao.com?token=ST-345678）🎜🎜🎜🎜🎜System A: 🎜 Senden Sie eine Anfrage an den CAS-Authentifizierungsdienst mit ST und Der CAS-Authentifizierungsdienst überprüft die Gültigkeit des Tickets (ST). Nach erfolgreicher Überprüfung weiß System A, dass sich der Benutzer bei CAS angemeldet hat (der darin enthaltene ST kann in Cookie oder lokal gespeichert werden. Der Server von System A verwendet das Ticket (ST), um eine Sitzung mit dem Benutzer zu erstellen, die als Teilsitzung bezeichnet wird ;🎜🎜🎜🎜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-Authentifizierungsdienstdirekt nach der Ausstellung desAuthorization Token STumgeleitet 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
AnmeldeticketWenn 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=readNach dem Login kopieren上面 URL 中，
response_type参数表示要求返回授权码（code），client_id参数让 B 知道是谁在请求，redirect_uri参数是 B 接受或拒绝请求后的跳转网址，scope参数表示要求的授权范围（这里是只读）
授权服务器：
授权服务网站会要求用户登录，然后询问是否同意给予 A 网站授权。用户表示同意，这时授权服务网站就会跳回redirect_uri参数指定的网址。跳转时，会传回一个授权码，就像下面这样。https://a.com/callback?code=AUTHORIZATION_CODENach 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_URLNach 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=readNach dem Login kopieren上面 URL 中，
response_type参数为token，表示要求直接返回令牌。授权服务器：
用户跳转到授权服务器，登录后同意给予 A 网站授权。这时，授权服务器就会跳回
redirect_uri参数指定的跳转网址，并且把令牌作为 URL 参数，传给 A 网站。https://a.com/callback#token=ACCESS_TOKENNach 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_IDNach 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_SECRETNach 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:
Laienhaft ausgedrückt: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
Verbundanmeldungbezieht 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.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, wasTrust Loginist.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, dassdas 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-Codeaktiv zu scannen und dann die Anmeldung zu bestätigen, damit sich dieselbe Anwendung auf dem PC schnell anmelden kann, istscan 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-CodeDer 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-codean 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 dasToken mit der QR-Code-IDverknü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 erhaltenenTemporären Tokenvorheriger 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 einformeller Tokenwird 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:
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:
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 Authenticationeignet 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-Cookieeignet sich für allgemeine mittlere und große Websites ( mobile APPs Außer);TokenundJWTsind für die meisten Unternehmenswebsites auf dem Markt geeignet, und die JWT-Leistung ist besser als TokenSingle Sign -On eignet sich für große Unternehmenswebsites mit vielen Subsystemen; <p></p> <code>OAuth 2.0eignet sich für Websites, die Benutzer schnell registrieren müssen;🎜Autor: Master Yi🎜 🎜🎜 (Lernvideo-Sharing: 🎜Web-Frontend🎜)🎜
QR-Code scannen, um sich anzumelden ist für bestehende Benutzer geeignet. Unternehmen, die die Bereitstellung von drei Terminals abgeschlossen haben. <a href="https://www.php.cn/course/list/1.html" target="_blank" textvalue="web前端"></a><code>Ein-Klick-Anmeldungist für native APP geeignet. /juejin.cn/post/7129298214959710244
So ändern Sie devc++ auf Chinesisch
Sonst-Verwendung in der Python-Schleifenstruktur
Der Unterschied zwischen Ankern und Zielen
Verwendung der isnumber-Funktion
Was sind die häufigsten Tomcat-Schwachstellen?
Lösung außerhalb des zulässigen Bereichs
So gleichen Sie Zahlen in regulären Ausdrücken ab
Was ist der Handel mit digitalen Währungen?
![[Zusammenfassungsfreigabe] 10 häufig verwendete Front-End- und Back-End-Authentifizierungsmethoden, damit Sie nicht länger verwirrt sind](https://img.php.cn/upload/image/777/687/105/166124862745570%5BZusammenfassungsfreigabe%5D%2010%20h%C3%A4ufig%20verwendete%20Front-End-%20und%20Back-End-Authentifizierungsmethoden,%20damit%20Sie%20nicht%20l%C3%A4nger%20verwirrt%20sind "166124862745570[Zusammenfassungsfreigabe] 10 häufig verwendete Front-End- und Back-End-Authentifizierungsmethoden, damit Sie nicht länger verwirrt sind")
![[Zusammenfassungsfreigabe] 10 häufig verwendete Front-End- und Back-End-Authentifizierungsmethoden, damit Sie nicht länger verwirrt sind](https://img.php.cn/upload/image/106/332/573/166124863438329%5BZusammenfassungsfreigabe%5D%2010%20h%C3%A4ufig%20verwendete%20Front-End-%20und%20Back-End-Authentifizierungsmethoden,%20damit%20Sie%20nicht%20l%C3%A4nger%20verwirrt%20sind "166124863438329[Zusammenfassungsfreigabe] 10 häufig verwendete Front-End- und Back-End-Authentifizierungsmethoden, damit Sie nicht länger verwirrt sind")
![1[Zusammenfassungsfreigabe] 10 häufig verwendete Front-End- und Back-End-Authentifizierungsmethoden, damit Sie nicht länger verwirrt sind](https://img.php.cn/upload/image/429/532/130/166124864137884%5BZusammenfassungsfreigabe%5D%2010%20h%C3%A4ufig%20verwendete%20Front-End-%20und%20Back-End-Authentifizierungsmethoden,%20damit%20Sie%20nicht%20l%C3%A4nger%20verwirrt%20sind "166124864137884[Zusammenfassungsfreigabe] 10 häufig verwendete Front-End- und Back-End-Authentifizierungsmethoden, damit Sie nicht länger verwirrt sind")
![1[Zusammenfassungsfreigabe] 10 häufig verwendete Front-End- und Back-End-Authentifizierungsmethoden, damit Sie nicht länger verwirrt sind](https://img.php.cn/upload/image/708/704/961/166124864761691%5BZusammenfassungsfreigabe%5D%2010%20h%C3%A4ufig%20verwendete%20Front-End-%20und%20Back-End-Authentifizierungsmethoden,%20damit%20Sie%20nicht%20l%C3%A4nger%20verwirrt%20sind "166124864761691[Zusammenfassungsfreigabe] 10 häufig verwendete Front-End- und Back-End-Authentifizierungsmethoden, damit Sie nicht länger verwirrt sind")
![1[Zusammenfassungsfreigabe] 10 häufig verwendete Front-End- und Back-End-Authentifizierungsmethoden, damit Sie nicht länger verwirrt sind](https://img.php.cn/upload/image/868/412/865/166124865346521%5BZusammenfassungsfreigabe%5D%2010%20h%C3%A4ufig%20verwendete%20Front-End-%20und%20Back-End-Authentifizierungsmethoden,%20damit%20Sie%20nicht%20l%C3%A4nger%20verwirrt%20sind "166124865346521[Zusammenfassungsfreigabe] 10 häufig verwendete Front-End- und Back-End-Authentifizierungsmethoden, damit Sie nicht länger verwirrt sind")
![1[Zusammenfassungsfreigabe] 10 häufig verwendete Front-End- und Back-End-Authentifizierungsmethoden, damit Sie nicht länger verwirrt sind](https://img.php.cn/upload/image/259/197/687/166124866070097%5BZusammenfassungsfreigabe%5D%2010%20h%C3%A4ufig%20verwendete%20Front-End-%20und%20Back-End-Authentifizierungsmethoden,%20damit%20Sie%20nicht%20l%C3%A4nger%20verwirrt%20sind "166124866070097[Zusammenfassungsfreigabe] 10 häufig verwendete Front-End- und Back-End-Authentifizierungsmethoden, damit Sie nicht länger verwirrt sind")
![1[Zusammenfassungsfreigabe] 10 häufig verwendete Front-End- und Back-End-Authentifizierungsmethoden, damit Sie nicht länger verwirrt sind](https://img.php.cn/upload/image/188/959/138/166124867037607%5BZusammenfassungsfreigabe%5D%2010%20h%C3%A4ufig%20verwendete%20Front-End-%20und%20Back-End-Authentifizierungsmethoden,%20damit%20Sie%20nicht%20l%C3%A4nger%20verwirrt%20sind "166124867037607[Zusammenfassungsfreigabe] 10 häufig verwendete Front-End- und Back-End-Authentifizierungsmethoden, damit Sie nicht länger verwirrt sind")
![1[Zusammenfassungsfreigabe] 10 häufig verwendete Front-End- und Back-End-Authentifizierungsmethoden, damit Sie nicht länger verwirrt sind](https://img.php.cn/upload/image/702/609/582/1661248678529660.png "1661248678529660.png")
![[Web-Frontend] Node.js-Schnellstart](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
