Concernant l'authentification frontale, que signifient le jeton, le cookie, la session, le JWT, l'authentification unique, la connexion par code scanné et la connexion en un clic ? Quelles sont les fonctions de chacun ? Comment faites-vous habituellement ? Et comment le stocker ? Alors, comment le garder en sécurité ? L'article suivant vous apprendra comment gérer tous les schémas d'authentification sur le front et le back-end, afin que vous ne soyez plus confus !
Je me souviens encore que lors de l'entretien, un intervieweur a demandé, concernant l'authentification frontale, que sont les Token, Cookie, Session, JWT et Single Sign-On ? Qu'est-ce que ça fait ? Comment faites-vous habituellement ? Et comment le stocker ? Alors, comment le garder en sécurité ? Token、Cookie、Session、JWT、单点登录是什么？有什么作用？你一般是怎么做的？以及你是怎么存储的呢？那你又是怎么保证 它 的安全的呢？
一顿连问下来，我是焦头又烂额，欲言而又止.......
其实鉴权的方法有很多，下面我总结了常用的 10种鉴权方法，那么哪一种是最适合你的系统呢？哪一种又最安全呢？
那就让我们从下文慢慢探索寻找答案吧 ~
在介绍鉴权方法之前，我们先要了解的是：什么是认证、授权、鉴权、权限控制以及他们之间的关系，有了他们做铺垫，那么我们才能做到从始至终的了解透彻 ~
认证(Identification) 是指根据声明者所特有的识别信息，确认声明者的身份。
白话文的意思就是：你需要用身份证证明你自己是你自己。
比如我们常见的认证技术：
授权(Authorization)： 在信息安全领域是指资源所有者委派执行者，赋予执行者指定范围的资源操作权限，以便对资源的相关操作。
在现实生活领域例如： 银行卡（由银行派发）、门禁卡（由物业管理处派发）、钥匙（由房东派发），这些都是现实生活中授权的实现方式。
在互联网领域例如： web 服务器的 session 机制、web 浏览器的 cookie 机制、颁发授权令牌（token）等都是一个授权的机制。
鉴权(Authentication) 在信息安全领域是指对于一个声明者所声明的身份权利，对其所声明的真实性进行鉴别确认的过程。
若从授权出发，则会更加容易理解鉴权。授权和鉴权是两个上下游相匹配的关系，先授权，后鉴权。
在现实生活领域： 门禁卡需要通过门禁卡识别器，银行卡需要通过银行卡识别器；
在互联网领域： 校验 session/cookie/token 的合法性和有效性
鉴权 是一个承上启下的一个环节，上游它接受授权的输出，校验其真实性后，然后获取权限（permission），这个将会为下一步的权限控制做好准备。
权限控制(Access/Permission Control) 将可执行的操作定义为权限列表，然后判断操作是否允许/禁止
对于权限控制，可以分为两部分进行理解：一个是权限，另一个是控制。权限是抽象的逻辑概念，而控制是具体的实现方式。
在现实生活领域中： 以门禁卡的权限实现为例，一个门禁卡，拥有开公司所有的门的权限；一个门禁卡，拥有管理员角色的权限，因而可以开公司所有的门。
在互联网领域： 通过 web 后端服务，来控制接口访问，允许或拒绝访问请求。
看到这里，我们应该明白了认证、授权、鉴权和权限控制这四个环节是一个前后依次发生、上下游
![[Partage du résumé] 10 méthodes dauthentification front-end et back-end couramment utilisées, pour que vous ne soyez plus confus](https://img.php.cn/upload/image/935/458/926/166124857181896%5BPartage%20du%20r%C3%A9sum%C3%A9%5D%2010%20m%C3%A9thodes%20dauthentification%20front-end%20et%20back-end%20couramment%20utilis%C3%A9es,%20pour%20que%20vous%20ne%20soyez%20plus%20confus "166124857181896[Partage du résumé] 10 méthodes dauthentification front-end et back-end couramment utilisées, pour que vous ne soyez plus confus")
. 10 méthodes d'authentification, alors laquelle est la plus adaptée à votre système ? Lequel est le plus sûr ?
Alors explorons lentement et trouvons la réponse parmi les éléments suivants ~
🎜🎜Avant d'introduire la méthode d'authentification, nous devons d'abord comprendre : 
Que sont l'authentification, l'autorisation, l'authentification, le contrôle d'autorisation et la relation entre eux, avec eux comme base, nous pouvons alors avoir une compréhension approfondie du début à la fin~🎜Authentification (Identification) fait référence à la confirmation de l'identité du déclarant sur la base des informations d'identification uniques du déclarant. 🎜🎜La signification en langue vernaculaire est : Vous devez utiliser votre carte d'identité pour prouver que vous êtes vous-même. 🎜🎜Par exemple, nos technologies d'authentification courantes : 🎜Autorisation : Dans le domaine de la sécurité de l'information, il s'agit du propriétaire de la ressource déléguant l'exécuteur pour accorder ExecutorSpécifie la plage d'autorisations d'opération de ressources pour effectuer des opérations associées sur les ressources. 🎜🎜Dans le domaine de la vie réelle, par exemple : Les cartes bancaires (distribuées par les banques), les cartes d'accès (distribuées par les syndics), les clés (distribuées par les propriétaires), ce sont autant de moyens de réaliser autorisation dans la vraie vie. 🎜🎜Dans le domaine Internet, par exemple : Le mécanisme de session du serveur web, le mécanisme de cookie du navigateur web et l'émission de jetons d'autorisation (tokens) sont tous des mécanismes d'autorisation. 🎜Authentification Dans le domaine de la sécurité de l'information, il s'agit de identifier et confirmer l'authenticité des droits d'identité déclarés par un déclarant. Le processus. de. 🎜🎜Si vous partez de l'autorisation, il sera plus facile de comprendre l'authentification. L'autorisation et l'authentification sont deux relations correspondantes en amont et en aval L'autorisation d'abord, puis l'authentification. 🎜🎜Dans le domaine réel : Les cartes de contrôle d'accès doivent transmettre l'identifiant de la carte d'accès, et les cartes bancaires doivent transmettre l'identifiant de la carte bancaire ; 🎜🎜Dans le domaine Internet : strong> Vérifier la session/le cookie La légalité et la validité de /token🎜🎜Authentification est un lien entre le précédent et le suivant. L'amont accepte la sortie autorisée, vérifie son authenticité, puis obtient l'autorisation. sera préparé pour la prochaine étape du contrôle des autorisations. 🎜Contrôle d'accès/permission Définissez les opérations exécutables sous forme de liste d'autorisations, puis déterminez si l'opération est autorisée/interdite🎜🎜Pour le contrôle des autorisations, elle peut être divisée en Là Il y a deux parties à comprendre : l’une concerne les autorisations et l’autre le contrôle. La permission est un concept logique abstrait, tandis que le contrôle est une méthode de mise en œuvre concrète. 🎜🎜Dans le domaine de la vie réelle : Prenons comme exemple la mise en œuvre des autorisations des cartes de contrôle d'accès. Une carte de contrôle d'accès a l'autorisation d'ouvrir toutes les portes de l'entreprise. du rôle d'administrateur, afin qu'il puisse ouvrir toutes les portes de l'entreprise. 🎜🎜Dans le domaine Internet : Contrôlez l'accès à l'interface via les services web backend, en autorisant ou en refusant les demandes d'accès. 🎜Authentification, Autorisation, Authentification et Contrôle des autorisations Ces quatre liens sont une relation se produisant séquentiellement avant et après, amont et aval 🎜🎜🎜🎜🎜Il est à noter que ces quatre liens se produiront parfois simultanément. Par exemple, dans les scènes suivantes : 🎜Voici une petite question à laquelle chacun doit réfléchir : Quelle est la relation entre authentification et authentification ? Tout le monde est invité à discuter dans la zone de commentaires
Maintenant que nous avons compris la relation entre eux, devrions-nous parler d'authentification frontale ? Et quelles sont les différences entre eux ?
Dans HTTP, Authentification d'accès de base) permet au client (généralement un navigateur Web) de transmettre l'utilisateur. fournit un nom d'utilisateur et un mot de passe pour vérifier l'identité de l'utilisateur. 基本认证方案（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
Étant donné que presque tous les sites Web en ligne n'utilisent pas ce système de certification, tout le monde peut comprendre le système
🎜1.1 Organigramme de certification 🎜 🎜🎜![[Partage du résumé] 10 méthodes dauthentification front-end et back-end couramment utilisées, pour que vous ne soyez plus confus](https://img.php.cn/upload/image/566/383/335/166124857782138%5BPartage%20du%20r%C3%A9sum%C3%A9%5D%2010%20m%C3%A9thodes%20dauthentification%20front-end%20et%20back-end%20couramment%20utilis%C3%A9es,%20pour%20que%20vous%20ne%20soyez%20plus%20confus "166124857782138[Partage du résumé] 10 méthodes dauthentification front-end et back-end couramment utilisées, pour que vous ne soyez plus confus")
🎜🎜🎜1.2 Analyse des étapes d'authentification🎜🎜liste restreinte de données ou de ressources au serveur, par exemple, les champs sont les suivants🎜eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
baidu . com est une ressource restreinte qui nécessite une authentification de base ; 🎜🎜 renvoie un code d'état 401 (Non autorisé) au client et fournit un domaine d'authentification www-Authenticate : Basic realm =”baidu.com” code> nécessite une authentification ; 🎜🎜où <code>Basic est le mode de vérification, et realm="baidu.com" indique que le client doit saisir le nom d'utilisateur et le mot de passe de ce domaine de sécurité. , pas le 🎜 {
"alg": "HS256",
"typ": "JWT"
} {
"sub": "1234567890",
"name": "John Doe",
"admin": true
}Autorisation C'est vrai, ceci. est la ressource que vous souhaitez. 🎜HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)
Session-Cookie L'authentification est un mode d'authentification de communication front-end et back-end mis en œuvre en utilisant la Session (session) du serveur et le Cookie. du navigateur (client) . Qu'est-ce qu'un cookie et Qu'est-ce qu'une session ? 🎜🎜🎜2.1 Qu'est-ce que Cookie🎜🎜🎜Comme nous le savons tous, HTTP est un protocole sans état (pas de capacité mémoire pour les transactions traitement, chaque fois que la session entre le client et le serveur est terminée, le serveur n'enregistre aucune information de session) ; 🎜🎜Donc, pour que le serveur puisse faire la distinction entre les différents clients, il doit maintenir activement un état, qui est utilisé pour informer le serveur avant et après si les deux requêtes proviennent du même navigateur. Cet état peut être atteint via Cookie. 🎜🎜🎜Caractéristiques :🎜🎜2.2 Qu'est-ce que Session
Le concept abstrait de Session est session, qui est une abstraction de l'interaction entre l'utilisateur et le serveur afin de réaliser une interruption /continuation de l'opération pendant le processus de communication du protocole sans état ;
Plus précisément, il s'agit du serveur. La structure de session générée peut être enregistrée de diverses manières, telles que la mémoire, la base de données, les fichiers, etc. Les grands sites Web ont généralement des clusters de serveurs de session dédiés pour enregistrer les sessions utilisateur ;
Processus principal :
Client : L'utilisateur envoie une requête au serveur pour la première fois
Serveur : reçoit les données et crée automatiquement une session spécifique/ ID de session permettant à l'utilisateur d'identifier l'utilisateur et de suivre le processus de session en cours de l'utilisateur ;
Fin du client : Le navigateur reçoit la réponse pour obtenir les informations de session et apportera la session / l'ID de session avec la prochaine demande ;
Serveur : Une fois que le serveur l'a extrait, il le comparera avec l'ID de session enregistré localement pour trouver la session de l'utilisateur spécifique, puis obtiendra l'état de la session
La communication entre le client et le serveur ; est maintenant devenu une communication avec état ;
Caractéristiques :
Le cookie est stocké côté client et peut être falsifié à volonté, tandis que la session est stockée côté serveur et ne peut pas être falsifiée, la session est donc plus sécurisée
Différents types de valeurs d'accès :Session-Cookie utilise-t-il simplement Session Est-il stocké dans le Cookie ?
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 去找服务端保存的该客户端的 sid2.3 Organigramme d'authentification par session-cookie
![[Partage du résumé] 10 méthodes dauthentification front-end et back-end couramment utilisées, pour que vous ne soyez plus confus](https://img.php.cn%20/%20upload/image/192/758/195/166124858574844%5BPartage%20du%20r%C3%A9sum%C3%A9%5D%2010%20m%C3%A9thodes%20dauthentification%20front-end%20et%20back-end%20couramment%20utilis%C3%A9es,%20pour%20que%20vous%20ne%20soyez%20plus%20confus "166124858574844[Partage du résumé] 10 méthodes dauthentification front-end et back-end couramment utilisées, pour que vous ne soyez plus confus")
Serveur : Vérifiez les informations de connexion et créez automatiquement une session après avoir réussi la vérification (enregistrez la session en mémoire ou dans Redis), puis générer une chaîne d'identification unique identifiant de session session_id (généralement appelé sid) pour cette session, et ajoutez-la dans l'en-tête de réponse Set-Cookie ;
![[Partage du résumé] 10 méthodes dauthentification front-end et back-end couramment utilisées, pour que vous ne soyez plus confus](https://img.php.cn/upload/image/192/758/195/166124858574844%5BPartage%20du%20r%C3%A9sum%C3%A9%5D%2010%20m%C3%A9thodes%20dauthentification%20front-end%20et%20back-end%20couramment%20utilis%C3%A9es,%20pour%20que%20vous%20ne%20soyez%20plus%20confus "166124858574844[Partage du résumé] 10 méthodes dauthentification front-end et back-end couramment utilisées, pour que vous ne soyez plus confus")
sid, et le serveur le déchiffrera en fonction de la clé secrète correspondante (étape facultative) 🎜 🎜🎜🎜🎜Client : 🎜 Après avoir reçu la réponse du serveur, il analysera l'en-tête de réponse et enregistrera automatiquement le sid dans le cookie local. Le navigateur utilisera le prochain HTTP lors de la création. une requête, l'en-tête de la requête sera automatiquement accompagné des informations du cookie sous le nom de domaine 🎜🎜🎜🎜🎜Serveur : 🎜 Lors de la réception d'une requête client, il analysera le sid dans l'en-tête de la requête Cookie ; , puis utilisez ce sid Recherchez le sid du client enregistré par le serveur, puis déterminez si la demande est légale 🎜🎜🎜🎜🎜🎜2.5 Avantages de la session ; -Cookie🎜🎜🎜🎜🎜Le cookie est simple Facile à utiliser🎜🎜Les données de session sont stockées côté serveur, par rapport à JWT, elles sont plus faciles à gérer, c'est-à-dire que lorsque l'utilisateur se connecte et se déconnecte activement, il n'en a besoin que. pour ajouter et supprimer la session correspondante. C'est facile à gérer🎜🎜Seules les opérations back-end sont nécessaires, le front-end peut être utilisé sans aucun sens 🎜🎜🎜🎜🎜2.6 Inconvénients de Session-Cookie🎜🎜🎜.Applicable aux sites Web généralement de taille moyenne et grande (sauf pour les terminaux mobiles APP) Étant donné que les sessions générales doivent être stockées de manière centralisée sur un serveur de mémoire (tel que Redis), cela augmentera le budget du serveur, donc si votre budget est insuffisant, veuillez choisir avec soin
Utilisez express : express-session
Session-Cookie et du maintien de la Session causent de gros problèmes au serveur. Nous devons trouver un endroit pour y accéder. stockez-le, et nous devons considérer le problème de la distribution, et même activer un serveur distinct pour cela. Existe-t-il une meilleure façon ? Token est né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 的缺点：
![[Partage du résumé] 10 méthodes dauthentification front-end et back-end couramment utilisées, pour que vous ne soyez plus confus](https://img.php.cn/upload/image/864/554/486/166124859229896%5BPartage%20du%20r%C3%A9sum%C3%A9%5D%2010%20m%C3%A9thodes%20dauthentification%20front-end%20et%20back-end%20couramment%20utilis%C3%A9es,%20pour%20que%20vous%20ne%20soyez%20plus%20confus "166124859229896[Partage du résumé] 10 méthodes dauthentification front-end et back-end couramment utilisées, pour que vous ne soyez plus confus")
sid 更大，消耗更多流量，挤占更多宽带Refresh Token；3.2 什么是 Refresh Token（刷新 Token）
业务接口用来鉴权的 Token，我们称之为 Access Token。
为了安全，我们的 Access Token 有效期一般设置较短，以避免被盗用。但过短的有效期会造成 Access Token 经常过期，过期后怎么办呢？
一种办法是：刷新 Access Token3.1 Qu'est-ce que Token
Token est un jeton, le client Lorsque le client accède au serveur , le serveur lui délivrera un jeton après avoir réussi la vérification. Après cela, le client peut apporter le jeton pour accéder au serveur, et le serveur n'a qu'à vérifier la validité du jeton. 🎜🎜En une phrase ; 🎜Les informations d'identification de la ressource requises lors de l'accès à l'interface de ressource (API) 🎜🎜🎜🎜Composition générale du jeton : 🎜🎜🎜🎜uid🎜 (identité unique de l'utilisateur) + tampon 🎜time🎜 (heure de l'heure actuelle) ) + 🎜sign🎜 (Signature, les premiers chiffres du Token sont compressés en une chaîne hexadécimale d'une certaine longueur à l'aide d'un algorithme de hachage) 🎜🎜🎜Organigramme d'authentification du Token : 🎜🎜🎜![[Partage du résumé] 10 méthodes dauthentification front-end et back-end couramment utilisées, pour que vous ne soyez plus confus](https://img%20.php.cn/upload/image/864/554/486/166124859229896%5BPartage%20du%20r%C3%A9sum%C3%A9%5D%2010%20m%C3%A9thodes%20dauthentification%20front-end%20et%20back-end%20couramment%20utilis%C3%A9es,%20pour%20que%20vous%20ne%20soyez%20plus%20confus "166124859229896[Partage du résumé] 10 méthodes dauthentification front-end et back-end couramment utilisées, pour que vous ne soyez plus confus")
🎜🎜🎜Analyse de l'étape d'authentification du jeton : 🎜🎜sid ; >. Consommez plus de trafic et occupez plus de bande passante🎜🎜🎜Problèmes de performances :🎜 Bien qu'il ne soit pas nécessaire d'accéder à la base de données ou au service à distance pour la vérification des autorisations lors de la vérification du jeton, des opérations telles que le cryptage et le déchiffrement du jeton sont donc nécessaires. consommera plus de performances ;🎜🎜 🎜Période de validité courte : 🎜 Afin d'éviter le vol du jeton, la période de validité du jeton est généralement définie pour être plus courte, il y a donc un Actualiser le jeton 🎜🎜🎜🎜 ; 🎜3.2 Qu'est-ce que le jeton d'actualisation🎜 🎜🎜🎜Le jeton utilisé pour l'authentification par l'interface métier est appelé Access Token. 🎜🎜Pour des raisons de sécurité, la durée de validité de notre Access Token est généralement fixée pour être plus courte afin d'éviter tout vol. Cependant, une période de validité trop courte entraînera l'expiration fréquente du Access Token. Que dois-je faire après son expiration ? 🎜🎜Une solution est : Actualiser le jeton d'accès, ce qui sera très difficile pour les utilisateurs de se reconnecter pour obtenir un nouveau jeton 🎜 ;另外一种办法是：再来一个 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 中通常包含了两部分：
![[Partage du résumé] 10 méthodes dauthentification front-end et back-end couramment utilisées, pour que vous ne soyez plus confus](https://img.php.cn/upload/image/724/427/748/166124859837135%5BPartage%20du%20r%C3%A9sum%C3%A9%5D%2010%20m%C3%A9thodes%20dauthentification%20front-end%20et%20back-end%20couramment%20utilis%C3%A9es,%20pour%20que%20vous%20ne%20soyez%20plus%20confus "166124859837135[Partage du résumé] 10 méthodes dauthentification front-end et back-end couramment utilisées, pour que vous ne soyez plus confus")
{
"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（主域名不同）
Dans nos sites Web commerciaux courants Tmall (tmall.com) et Taobao (taobao.com), nous n'avons besoin que de nous connecter à l'un des systèmes, et l'autre système se connectera par défaut après l'avoir ouvert. Alors, comment faire. ce?
Ensuite, il y a le service d'autorisation central CAS (Central Authentication Service), parlons donc d'abord du processus de 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 一般提供四个接口：
![[Partage du résumé] 10 méthodes dauthentification front-end et back-end couramment utilisées, pour que vous ne soyez plus confus](https://img.php.cn/upload/image/897/341/729/166124860695111%5BPartage%20du%20r%C3%A9sum%C3%A9%5D%2010%20m%C3%A9thodes%20dauthentification%20front-end%20et%20back-end%20couramment%20utilis%C3%A9es,%20pour%20que%20vous%20ne%20soyez%20plus%20confus "166124860695111[Partage du résumé] 10 méthodes dauthentification front-end et back-end couramment utilisées, pour que vous ne soyez plus confus")
/login：登录接口，用于登录到中央授权服务/logout：登出接口，用于从中央授权服务中登出/validate：用于验证用户是否登录中央授权服务/serviceValidate：用于让各个 Service 验证用户是否登录中央授权服务CAS 生成的票据：
登录票据
![[Partage du résumé] 10 méthodes dauthentification front-end et back-end couramment utilisées, pour que vous ne soyez plus confus](https://img.php.cn/upload/image/323/229/797/166124861395999%5BPartage%20du%20r%C3%A9sum%C3%A9%5D%2010%20m%C3%A9thodes%20dauthentification%20front-end%20et%20back-end%20couramment%20utilis%C3%A9es,%20pour%20que%20vous%20ne%20soyez%20plus%20confus "166124861395999[Partage du résumé] 10 méthodes dauthentification front-end et back-end couramment utilisées, pour que vous ne soyez plus confus")
Système A ; : Il s'avère que l'utilisateur n'est pas connecté et est redirigé vers le service d'authentification CAS (sso.com). En même temps, le paramètre d'adresse URL porte le lien de la page du système A après une connexion réussie (sso.com/login ?redir…
Non connecté et a réessayé. Dirigez la page utilisateur vers l'interface de connexion CAS et l'utilisateur se connecte sur la page de connexion CAS 🎜🎜🎜🎜🎜Client. : 🎜 Entrez le nom d'utilisateur et le mot de passe pour l'authentification du système CAS ; 🎜🎜🎜🎜🎜 Service d'authentification CAS : 🎜 Vérification des informations utilisateur, et générez TGC et placez-le dans votre propre session, puis écrivez-le dans le formulaire. de Set-Cookie sous le domaine dont le Domaine est sso.com en même temps, générer un Jeton d'autorisation ST (Service Ticket), puis rediriger vers l'adresse de système A. L'adresse redirigée contient le ST généré (adresse de redirection : www.taobao.com?token=ST-345678）🎜🎜🎜🎜🎜Système A : 🎜 Envoyer une demande au service d'authentification CAS avec ST, et le service d'authentification CAS vérifie la validité du ticket (ST). Après une vérification réussie, le système A sait que l'utilisateur s'est connecté au CAS (le ST peut être enregistré dans un cookie ou localement). Le serveur du système A utilise le ticket (ST) pour créer une session avec l'utilisateur, appelée session partielle, et renvoie les ressources protégées. ;🎜🎜🎜🎜À ce stade, le client peut avoir une relation agréable avec le système A~🎜
🎜(PS : c'est un peu salaud d'avoir deux bateaux~)🎜🎜🎜Choses à noter sous un seul signe- on Point : 🎜🎜
service d'authentification CAS redirigé directement après avoir émis le jeton d'autorisation ST, donc en fait, il est relativement facile d'être volé, nous devons alors générer un autre nouveau jeton de vérification et le renvoyer au client pour stockage une fois que le système A ou le système B s'est authentifié avec succès auprès du CAS (étapes 14 et 11 de la figure 🎜🎜🎜🎜CAS) ; fournit généralement quatre interfaces : 🎜/login : interface de connexion, utilisée pour se connecter au service d'autorisation central 🎜🎜/logout : interface de déconnexion, utilisée pour se déconnecter du service d'autorisation central🎜🎜/validate : utilisé pour vérifier si l'utilisateur est connecté au service d'autorisation central🎜🎜/serviceValidate : utilisé pour autoriser chaque service pour vérifier si l'utilisateur se connecte au service d'autorisation central🎜🎜🎜🎜🎜Tickets générés par CAS : 🎜ticket de connexion émis par CAS pour l'utilisateur et que vous disposez d'un TGT, l'utilisateur peut prouver qu'il s'est connecté avec succès au CAS. 🎜🎜🎜TGC : Ticket Granting Cookie : 🎜 CAS Server génère le TGT et le place dans sa propre Session, et TGC est l'identifiant unique (SessionId) de cette Session. Il est placé côté navigateur sous la forme d'un cookie. est utilisé par CAS Server pour clarifier l'identité des informations d'identification de l'utilisateur. 🎜🎜🎜ST (Service Ticket)🎜 : ST est un ticket émis par CAS pour permettre à l'utilisateur d'accéder à un Service. 🎜🎜🎜🎜🎜🎜6. OAuth 2.0🎜🎜🎜🎜Lorsque nous parcourons réellement le site Web, en plus de saisir le compte et le mot de passe du site Web actuel lorsque nous nous connectons, nous constatons également que nous pouvons nous connecter via un tiers. QQ ou WeChat, alors Comment faire ça ? Parlons de 🎜OAuth🎜. 🎜🎜OAuth 协议又有 1.0 和 2.0 两个版本，2.0 版整个授权验证流程更简单更安全，也是目前最主要的用户身份验证和授权方式。
6.1 什么是 OAuth 2.0？
OAuth 是一个开放标准，允许用户授权第三方网站 (CSDN、思否等) 访问他们存储在另外的服务提供者上的信息，而不需要将用户名和密码提供给第三方网站；
常见的提供 OAuth 认证服务的厂商： 支付宝、QQ、微信、微博
简单说，OAuth 就是一种授权机制。数据的所有者告诉系统，同意授权第三方应用进入系统，获取这些数据。系统从而产生一个短期的进入令牌（Token），用来代替密码，供第三方应用使用。
令牌与密码的差异：
令牌（Token） 与 密码（Password） 的作用是一样的，都可以进入系统，但是有三点差异。
令牌是短期的，到期会自动失效： 用户自己无法修改。密码一般长期有效，用户不修改，就不会发生变化。
令牌可以被数据所有者撤销，会立即失效。
令牌有权限范围（scope）： 对于网络服务来说，只读令牌就比读写令牌更安全。密码一般是完整权限。
OAuth 2.0 对于如何颁发令牌的细节，规定得非常详细。具体来说，一共分成四种授权模式 （Authorization Grant） ，适用于不同的互联网场景。
无论哪个模式都拥有三个必要角色：客户端、授权服务器、资源服务器，有的还有用户（资源拥有者），下面简单介绍下四种授权模式。
6.2 授权码模式
授权码（Authorization Code Grant) 方式，指的是第三方应用先申请一个授权码，然后再用该码获取令牌。
这种方式是最常用的流程，安全性也最高，它适用于那些有后端服务的 Web 应用。授权码通过前端传送，令牌则是储存在后端，而且所有与资源服务器的通信都在后端完成。这样的前后端分离，可以避免令牌泄漏。
一句话概括：客户端换取授权码，客户端使用授权码换token，客户端使用token访问资源
客户端：
打开网站 A，点击登录按钮，请求 A 服务，A 服务重定向 (重定向地址如下) 至授权服务器 (如QQ、微信授权服务)。
https://qq.com/oauth/authorize? response_type=code& client_id=CLIENT_ID& redirect_uri=CALLBACK_URL& scope=read
上面 URL 中，response_type 参数表示要求返回授权码（code），client_id 参数让 B 知道是谁在请求，redirect_uri 参数是 B 接受或拒绝请求后的跳转网址，scope 参数表示要求的授权范围（这里是只读）
授权服务器：
授权服务网站 会要求用户登录，然后询问是否同意给予 A 网站授权。用户表示同意，这时授权服务网站 就会跳回 redirect_uri 参数指定的网址。跳转时，会传回一个授权码，就像下面这样。
https://a.com/callback?code=AUTHORIZATION_CODE
上面 URL 中，code 参数就是授权码。
网站 A 服务器：
拿到授权码以后，就可以向 授权服务器 (qq.com) 请求令牌，请求地址如下：
https://qq.com/oauth/token? client_id=CLIENT_ID& client_secret=CLIENT_SECRET& grant_type=authorization_code& code=AUTHORIZATION_CODE& redirect_uri=CALLBACK_URL
上面 URL 中，client_id 参数和 client_secret 参数用来让授权服务器 确认 A 的身份（client_secret 参数是保密的，因此只能在后端发请求），grant_type参数的值是AUTHORIZATION_CODE，表示采用的授权方式是授权码，code 参数是上一步拿到的授权码，redirect_uri 参数是令牌颁发后的回调网址。
授权服务器：
收到请求以后，验证通过，就会颁发令牌。具体做法是向 redirect_uri 指定的网址，发送一段 JSON 数据。
![[Partage du résumé] 10 méthodes dauthentification front-end et back-end couramment utilisées, pour que vous ne soyez plus confus](https://img.php.cn/upload/image/777/687/105/166124862745570%5BPartage%20du%20r%C3%A9sum%C3%A9%5D%2010%20m%C3%A9thodes%20dauthentification%20front-end%20et%20back-end%20couramment%20utilis%C3%A9es,%20pour%20que%20vous%20ne%20soyez%20plus%20confus "166124862745570[Partage du résumé] 10 méthodes dauthentification front-end et back-end couramment utilisées, pour que vous ne soyez plus confus")
![[Partage du résumé] 10 méthodes dauthentification front-end et back-end couramment utilisées, pour que vous ne soyez plus confus](https://img.php.cn/upload/image/106/332/573/166124863438329%5BPartage%20du%20r%C3%A9sum%C3%A9%5D%2010%20m%C3%A9thodes%20dauthentification%20front-end%20et%20back-end%20couramment%20utilis%C3%A9es,%20pour%20que%20vous%20ne%20soyez%20plus%20confus "166124863438329[Partage du résumé] 10 méthodes dauthentification front-end et back-end couramment utilisées, pour que vous ne soyez plus confus")
![1[Partage du résumé] 10 méthodes dauthentification front-end et back-end couramment utilisées, pour que vous ne soyez plus confus](https://img.php.cn/upload/image/429/532/130/166124864137884%5BPartage%20du%20r%C3%A9sum%C3%A9%5D%2010%20m%C3%A9thodes%20dauthentification%20front-end%20et%20back-end%20couramment%20utilis%C3%A9es,%20pour%20que%20vous%20ne%20soyez%20plus%20confus "166124864137884[Partage du résumé] 10 méthodes dauthentification front-end et back-end couramment utilisées, pour que vous ne soyez plus confus")
{
"access_token":"ACCESS_TOKEN",
"token_type":"bearer",
"expires_in":2592000,
"refresh_token":"REFRESH_TOKEN",
"scope":"read",
"uid":100101,
"info":{...}
}上面 JSON 数据中，access_token 字段就是令牌，A 网站在后端拿到了，然后返回给客户端即可。
6.3 隐藏式模式（Implicit Grant）
有些 Web 应用是纯前端应用，没有后端。这时就不能用上面的方式了，必须将令牌储存在前端。OAuth2.0 就规定了第二种方式，允许直接向前端颁发令牌。这种方式没有授权码这个中间步骤，所以称为（授权码）"隐藏式"（implicit）。
一句话概括：客户端让用户登录授权服务器换token，客户端使用token访问资源。
客户端：
打开网站 A，A 网站提供一个链接，要求用户跳转到 授权服务器，授权用户数据给 A 网站使用。如下链接：
https://qq.com/oauth/authorize? response_type=token& client_id=CLIENT_ID& redirect_uri=CALLBACK_URL& scope=read
上面 URL 中，response_type参数为token，表示要求直接返回令牌。
授权服务器：
用户跳转到授权服务器，登录后同意给予 A 网站授权。这时，授权服务器就会跳回redirect_uri 参数指定的跳转网址，并且把令牌作为 URL 参数，传给 A 网站。
https://a.com/callback#token=ACCESS_TOKEN
上面 URL 中，token参数就是令牌，A 网站因此直接在前端拿到令牌。
注意：
令牌的位置是 URL 锚点（fragment），而不是查询字符串（querystring），这是因为 OAuth 2.0 允许跳转网址是 HTTP 协议，因此存在"中间人攻击"的风险，而浏览器跳转时，锚点不会发到服务器，就减少了泄漏令牌的风险。
这种方式把令牌直接传给前端，是很不安全的。因此，只能用于一些安全要求不高的场景，并且令牌的有效期必须非常短，通常就是会话期间（session）有效，浏览器关掉，令牌就失效了。
6.4 用户名密码式模式（Password Credentials Grant）
如果你高度信任某个应用，OAuth 2.0 也允许用户把用户名和密码，直接告诉该应用。该应用就使用你的密码，申请令牌，这种方式称为"密码式"（password）。
一句话概括：用户在客户端提交账号密码换token，客户端使用token访问资源。
客户端：
A 网站要求用户提供 授权服务器(qq.com) 的用户名和密码。拿到以后，A 就直接向 授权服务器 请求令牌。
https://oauth.b.com/token? grant_type=password& username=USERNAME& password=PASSWORD& client_id=CLIENT_ID
上面 URL 中，grant_type参数是授权方式，这里的password表示"密码式"，username和password是 授权服务器 的用户名和密码。
授权服务器：
授权服务器 验证身份通过后，直接给出令牌。
注意，这时不需要跳转，而是把令牌放在 JSON 数据里面，作为 HTTP 回应，A 网站因此拿到令牌。
这种方式需要用户给出自己的用户名/密码，显然风险很大，因此只适用于其他授权方式都无法采用的情况，而且必须是用户高度信任的应用。
6.5 客户端模式（Client Credentials Grant）
客户端模式指客户端以自己的名义，而不是以用户的名义，向授权服务器 进行认证。
主要适用于没有前端的命令行应用。
一句话概括：客户端使用自己的标识换token，客户端使用token访问资源。
客户端：
客户端向授权服务器 进行身份认证，并要求一个访问令牌。请求链接地址：
https://oauth.b.com/token? grant_type=client_credentials& client_id=CLIENT_ID& client_secret=CLIENT_SECRET
上面 URL 中，grant_type参数等于client_credentials表示采用凭证式，client_id和client_secret用来让授权服务器 确认 A 的身份。
授权服务器：
授权服务器 验证通过以后，直接返回令牌。
注意：这种方式给出的令牌，是针对第三方应用的，而不是针对用户的，即有可能多个用户共享同一个令牌。
6.5 授权模式选型
| 模式 | 需要前端 | 需要后端 | 需要用户响应 | 需要客户端密钥 |
|---|---|---|---|---|
| 授权码模式 Authorization Code | ✅ | ✅ | ✅ | ✅ |
| 隐式授权模式 Implicit Grant | ✅ | ❌ | ✅ | ❌ |
| 密码授权模式 Password Grant | ✅ | ✅ | ✅ | ✅ |
| 客户端授权模式 Client Credentials | ❌ | ✅ | ❌ | ✅ |
Ce qui précède explique principalement la logique de base d'OAuth2.0 de manière simple. Si vous souhaitez en savoir plus en détail, vous pouvez consulter le. documentation officielleOAuth ou RFC 6749 Vous pouvez également consulter le Résumé du concept et du processus d'autorisation OAuth 2.0 pour comparaison
Connexion fédérée fait référence à un service de connexion qui inclut plusieurs vérifications d'informations d'identification en même temps, il peut également être compris comme un service de connexion qui utilise des tiers. informations d'identification du parti pour vérification.
Ce concept est en fait similaire à la méthode d'authentification OAuth2.0 Username Password Mode mentionnée ci-dessus. Le plus classique est le scénario d'utilisation du H5 intégré dans l'APP. Lorsque les utilisateurs entrent dans le H5 intégré depuis l'APP, nous espérons que les utilisateurs connectés à l'APP pourront accéder aux ressources restreintes dans H5, tandis que les utilisateurs non connectés ne peuvent pas nécessiter une connexion. pour accéder.
Il y a deux idées principales ici. L'une consiste à attacher le jeton de connexion au paramètre URL lors du passage à la page H5 intégrée de manière native. L'autre consiste à intégrer H5 pour obtenir activement l'application via le protocole établi avec la connexion client native. statut à l’intérieur.
联合登录 指同时包含多种凭证校验的登录服务，同时，也可以理解为使用第三方凭证进行校验的登录服务。
通俗点讲： 对于两个网站 A 和 B，在登录 A 网站的时候用 B 网站的帐号密码，就是联合登录，或者登录 B 网站的时候使用 A 网站的帐号密码，也是联合登录。
这样的概念其实与上面所讲的 OAuth2.0 的 用户名密码式模式 认证方式类似。
最经典的莫过于 APP 内嵌 H5 的使用场景，当用户从 APP 进入内嵌的 H5 时，我们希望 APP 内已登录的用户能够访问到 H5 内受限的资源，而未登录的用户则需要登录后访问。
这里思路主要有两种，一种是原生跳转内嵌 H5 页面时，将登录态 Token 附加在 URL 参数上，另一种则是内嵌 H5 主动通过与原生客户端制定的协议获取应用内的登录状态。
7.2 什么是信任登录
信任登录 是指所有不需要用户主动参与的登录，例如建立在私有设备与用户之间的绑定关系，凭证就是私有设备的信息，此时不需要用户再提供额外的凭证。信任登录又指用第三方比较成熟的用户库来校验凭证，并登录当前访问的网站。
通俗点讲： 在 A 网站有登录状态的时候，可以直接跳转到 B 网站而不用登录，就是 信任登录
![1[Partage du résumé] 10 méthodes dauthentification front-end et back-end couramment utilisées, pour que vous ne soyez plus confus](https://img.php.cn/upload/image/708/704/961/166124864761691%5BPartage%20du%20r%C3%A9sum%C3%A9%5D%2010%20m%C3%A9thodes%20dauthentification%20front-end%20et%20back-end%20couramment%20utilis%C3%A9es,%20pour%20que%20vous%20ne%20soyez%20plus%20confus "166124864761691[Partage du résumé] 10 méthodes dauthentification front-end et back-end couramment utilisées, pour que vous ne soyez plus confus")
![1[Partage du résumé] 10 méthodes dauthentification front-end et back-end couramment utilisées, pour que vous ne soyez plus confus](https://img.php.cn/upload/image/868/412/865/166124865346521%5BPartage%20du%20r%C3%A9sum%C3%A9%5D%2010%20m%C3%A9thodes%20dauthentification%20front-end%20et%20back-end%20couramment%20utilis%C3%A9es,%20pour%20que%20vous%20ne%20soyez%20plus%20confus "166124865346521[Partage du résumé] 10 méthodes dauthentification front-end et back-end couramment utilisées, pour que vous ne soyez plus confus")
![1[Partage du résumé] 10 méthodes dauthentification front-end et back-end couramment utilisées, pour que vous ne soyez plus confus](https://img.php.cn/upload/image/259/197/687/166124866070097%5BPartage%20du%20r%C3%A9sum%C3%A9%5D%2010%20m%C3%A9thodes%20dauthentification%20front-end%20et%20back-end%20couramment%20utilis%C3%A9es,%20pour%20que%20vous%20ne%20soyez%20plus%20confus "166124866070097[Partage du résumé] 10 méthodes dauthentification front-end et back-end couramment utilisées, pour que vous ne soyez plus confus")
Connexion de confiance fait référence à toutes les connexions qui ne nécessitent pas la participation active de l'utilisateur, comme une relation de liaison établie entre un appareil privé et l'utilisateur, et les informations d'identification sont des informations privées sur l'appareil, l'utilisateur n'a pas besoin de fournir d'informations d'identification supplémentaires pour le moment. La connexion sécurisée fait également référence à l’utilisation d’une bibliothèque d’utilisateurs tierce relativement mature pour vérifier les informations d’identification et se connecter au site Web que vous visitez actuellement. connexion de confiance. Les comptes de connexion tiers de confiance actuellement courants incluent : le compte QQ Taobao, le compte Alipay, le compte Weibo, etc. Il n'est pas difficile pour nous de constater qu'OAthuth 2.0 est en fait la quintessence de la connexion de confiance, car c'est avec OAuth que notre connexion de confiance peut être réalisée.
8. Connexion unique
— Supposons que le chef de produit fasse maintenant une demande : Je veux réaliser que les utilisateurs ne peuvent se connecter que sur un seul appareil et interdire aux utilisateurs de se connecter à plusieurs reprises
— En tant que excellent programmeur Bien sûr nous le satisfaisons ! !
8.1 Qu'est-ce que la connexion unique ?
La connexion unique fait référence à l'interdiction à plusieurs personnes de se connecter au même compte en même temps. Le comportement de connexion de cette dernière entraînera la déconnexion de la première.
Pour faire simple![1[Partage du résumé] 10 méthodes dauthentification front-end et back-end couramment utilisées, pour que vous ne soyez plus confus](https://img.php.cn/upload/image/425/646/298/166124866574690%5BPartage%20du%20r%C3%A9sum%C3%A9%5D%2010%20m%C3%A9thodes%20dauthentification%20front-end%20et%20back-end%20couramment%20utilis%C3%A9es,%20pour%20que%20vous%20ne%20soyez%20plus%20confus "166124866574690[Partage du résumé] 10 méthodes dauthentification front-end et back-end couramment utilisées, pour que vous ne soyez plus confus")
8.2 Organigramme de connexion unique
Opération utilisateur sur le client A :
Le backend génère le Token correspondant et le renvoie au Client A, et enregistre un statut de connexion sur le serveur
Le Client A enregistre le Token, et chaque requête porte le Token correspondant dans l'en-tête ;Opération utilisateur sur le client B :
C'est juste que le backend génère un nouveau ; Token , vous devez d'abord vérifier le statut de connexion, puis générer le nouveau Token correspondant 9. Scannez le code pour vous connecter
La connexion par code QR se trouve généralement dans les applications mobiles. De nombreux sites Web PC offrent la fonction de numérisation de connexion par code QR. Il n'est pas nécessaire de saisir un compte et un mot de passe sur la page Web. Il vous suffit de saisir l'application mobile (telle que WeChat). , Taobao, QQ, etc.) La façon pour les utilisateurs connectés de scanner activement le code QR puis de confirmer la connexion afin que la même application sur le PC puisse se connecter rapidement est de scanner la connexion par code . 二维码 ，再确认登录，以使 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
![1[Partage du résumé] 10 méthodes dauthentification front-end et back-end couramment utilisées, pour que vous ne soyez plus confus](https://img.php.cn/upload/image/188/959/138/166124867037607%5BPartage%20du%20r%C3%A9sum%C3%A9%5D%2010%20m%C3%A9thodes%20dauthentification%20front-end%20et%20back-end%20couramment%20utilis%C3%A9es,%20pour%20que%20vous%20ne%20soyez%20plus%20confus "166124867037607[Partage du résumé] 10 méthodes dauthentification front-end et back-end couramment utilisées, pour que vous ne soyez plus confus")
Code QR est également appelé code QR. Le code QR commun est QR Code. Il s'agit d'un code QR mobile qui a. a été développé ces dernières années. Méthode d'encodage très populaire sur les appareils, elle peut stocker plus d'informations et représenter plus de types de données que le code à barres traditionnel. Grâce à ce qui précède, nous pouvons facilement constater que scanner le code QR pour se connecter nécessite trois terminaux (Terminal PC, Terminal mobile, Terminal serveur). La coopération est nécessaire pour réussir la connexion Étape à scanner :
Côté PC :
Ouvrez le portail de connexion par scan code d'un site Web (tel que taobao.com ) ou une application (telle que WeChat) ; les informations sur l'appareil du PC seront envoyées au service. Le client envoie une demande pour obtenir le code QR
Serveur :
![1[Partage du résumé] 10 méthodes dauthentification front-end et back-end couramment utilisées, pour que vous ne soyez plus confus](https://img.php.cn/upload/image/188%20/959/138/%20166124867037607%5BPartage%20du%20r%C3%A9sum%C3%A9%5D%2010%20m%C3%A9thodes%20dauthentification%20front-end%20et%20back-end%20couramment%20utilis%C3%A9es,%20pour%20que%20vous%20ne%20soyez%20plus%20confus "166124867037607[Partage du résumé] 10 méthodes dauthentification front-end et back-end couramment utilisées, pour que vous ne soyez plus confus")
informations sur le périphérique côté PC qui sont associées et stockées dans le serveur Redis, puis renvoyées au PC en même temps, une expiration ; l'heure est définie. Après l'expiration, le code QR de connexion de l'utilisateur doit être actualisé et réacquis.
Terminal PC :
Après avoir reçu l'ID du code QR, affichez l'ID du code QR sous la forme deCode QR et attendez que le terminal mobile scanne le code. Et à ce moment-là, le PC commence à interroger pour vérifier l'état du code QR jusqu'à ce que la connexion soit réussie. 🎜🎜Si le terminal mobile n'est pas scanné, le code QR expirera automatiquement après un certain temps. 🎜🎜🎜🎜🎜 Code scanné en attente de confirmation : 🎜🎜🎜🎜🎜🎜Version mobile : 🎜🎜🎜Ouvrez l'application (WeChat ou Taobao, etc.) correspondant à 🎜connecté🎜 sur le téléphone mobile, et commencez à scanner et à identifier le Code QR 2D affiché sur le code PC ; 🎜🎜Une fois que le terminal mobile a scanné le code QR, il obtiendra automatiquement l'ID du code QR et enverra le bon d'information de connexion du terminal mobile (jeton) et l'ID du code QR comme paramètres au serveur. À ce stade, le téléphone mobile doit être connecté (la condition préalable à l'utilisation de la connexion par numérisation est que l'application mobile soit connectée, afin que l'état de connexion puisse être partagé). 🎜🎜🎜🎜🎜Serveur : 🎜🎜🎜Après avoir reçu la demande du téléphone mobile, il associera le Token à l'ID du code QR. Pourquoi doit-il être associé ? Car lorsque nous utilisons WeChat et que nous nous déconnectons du côté mobile, le côté PC doit également se déconnecter. Cette association joue ce rôle. Ensuite, un jeton temporaire sera généré, qui sera renvoyé au terminal mobile, et le jeton unique sera utilisé comme bon de confirmation. 🎜🎜🎜🎜🎜 Étape confirmée : 🎜🎜🎜🎜🎜🎜Terminal mobile : 🎜🎜🎜Après avoir reçu le message de confirmation, cliquez sur le bouton de confirmation, et le terminal mobile portera le Jeton temporaire obtenu dans le étape précédente et envoyez-le à la vérification côté serveur ; 🎜🎜🎜🎜🎜Côté serveur : 🎜🎜🎜Une fois la vérification côté serveur terminée, le statut du code QR sera mis à jour et un jeton formel sera généré pour le côté PC suivant. Maintenez simplement ce jeton pour accéder au serveur. 🎜🎜🎜🎜🎜Côté PC : 🎜🎜🎜Le statut du code QR interrogé est connecté, et le jeton généré sera obtenu, la connexion est terminée et les visites ultérieures sont effectuées en fonction du jeton. 10. Connexion en un clic (applicable à l'application native) est de utilisez 🎜Connectez-vous au compte avec un mot de passe 🎜, c'est simple et grossier, et généralement il n'y aura aucun problème 🎜🎜🎜Inconvénients : 🎜🎜🎜🎜🎜Mais cette méthode oblige les utilisateurs à se souvenir de leur numéro de compte et de leur mot de passe ; est un coût en mémoire. Afin de réduire les coûts de mémoire, les utilisateurs sont susceptibles d'utiliser le même ensemble de mots de passe de compte sur différentes plates-formes. Du point de vue de la sécurité, une fois que le mot de passe du compte d'une certaine plateforme est divulgué, les autres plateformes utilisées par l'utilisateur seront affectées. 🎜🎜🎜🎜De plus, puisque le compte n'a rien à voir avec l'identité personnelle, cela signifie que le même utilisateur peut enregistrer plusieurs comptes différents, ce qui signifie qu'un enregistrement malveillant peut se produire. 🎜🎜🎜🎜🎜Jusqu'à ce que le système obligatoire de nom réel pour les cartes de téléphone portable soit résolu ! 🎜🎜10.2 Connexion au code de vérification du numéro de téléphone portable
Avec le développement de l'Internet sans fil et la promotion du système de nom réel de la carte de téléphone portable, le numéro de téléphone mobile est devenu un certificat d'identité spécial par rapport au mot de passe du compte, au numéro de téléphone mobile. peut mieux vérifier l'identité de l'utilisateur pour empêcher un enregistrement malveillant.
Cependant, l'enregistrement d'un numéro de téléphone mobile nécessite encore une série d'opérations fastidieuses : saisir le numéro de téléphone mobile, attendre le code de vérification SMS, saisir le code de vérification et cliquer pour se connecter. L'ensemble du processus prend au moins vingt secondes, et si vous ne recevez pas le message texte, vous devez vous connecter pour compenser. Ce type de problème peut entraîner une perte potentielle d'utilisateur.
Du point de vue de la sécurité, il existe également un risque de fuite du code de vérification. Si quelqu'un connaît votre numéro de téléphone portable et vole le code de vérification, il peut également se connecter à votre compte.
Il y a donc une opération de connexion en un clic !
10.3 Qu'est-ce que la connexion en un clic
Réfléchissons-y, pourquoi avons-nous besoin d'un code de vérification ? La fonction du code de vérification est de confirmer que le numéro de téléphone mobile est le vôtre En plus d'utiliser des messages texte, existe-t-il un autre moyen d'authentifier le numéro de téléphone mobile ?
Ainsi, notre protagoniste peut se connecter en un seul clic.
La fonction du code de vérification SMS est de prouver que l'utilisateur de la page d'opération en cours et l'utilisateur qui a saisi le numéro de téléphone portable sont la même personne, tant que nous pouvons obtenir le numéro de carte de téléphone portable utilisé par. le téléphone mobile actuel, nous pouvons utiliser directement ce numéro pour nous connecter, sans frais supplémentaires. L'opération est Connexion en un clic.
La possibilité d'effectuer une connexion en un clic dépend du fait que l'opérateur ouvre ou non les services associés ; lorsque l'opérateur ouvre les services associés, nous pouvons désormais accéder au SDK fourni par l'opérateur et payer pour utiliser les services associés.
Organigramme de connexion en un clic :
![1[Partage du résumé] 10 méthodes dauthentification front-end et back-end couramment utilisées, pour que vous ne soyez plus confus](https://img.php.cn/upload/image/702/609/582/1661248678529660.png "1661248678529660.png")
Explication détaillée des étapes de connexion en un clic :
Initialisation du SDK : Appelez la méthode SDK et transmettez l'AppKey et l'AppSecret configurés par le platform
Page d'autorisation d'éveil : Appelez le SDK pour appeler l'interface d'autorisation. Le SDK lancera d'abord une demande à l'opérateur pour obtenir le masque de numéro de téléphone mobile. Une fois la demande réussie, il passera à l'autorisation. page. La page d'autorisation affichera le masque du numéro de téléphone mobile et l'accord de l'opérateur pour la confirmation de l'utilisateur.
Acceptez l'autorisation et connectez-vous : L'utilisateur accepte l'accord correspondant et clique sur le bouton de connexion sur la page d'autorisation. Une fois la demande réussie, le SDK demandera le jeton. être renvoyé au client
Obtenez le numéro : Envoyez le jeton obtenu à votre propre serveur, et le serveur portera le jeton et appellera l'interface de connexion en un clic de l'opérateur si l'appel réussit, le téléphone mobile. le numéro sera retourné. Le serveur utilise le numéro de téléphone mobile pour se connecter ou s'inscrire, et renvoie les résultats de l'opération au client pour terminer la connexion en un clic.
Trois plateformes ouvertes des principaux opérateurs :
China Unicom - Plateforme ouverte WO+
Les trois principaux opérateurs nationaux disposant chacun de SDK indépendants, le travail de compatibilité sera particulièrement fastidieux. Si vous souhaitez utiliser une solution de connexion en un clic, vous souhaiterez peut-être faire appel à un tiers pour fournir des services d'authentification par numéro. Les fournisseurs suivants disposent de capacités d'authentification par numéro de téléphone mobile :
Remarque :
Pendant le processus d'authentification, l'utilisateur doit activer le réseau cellulaire s'il est mobile. l'appareil n'a pas de carte SIM insérée ou le réseau cellulaire est désactivé. Dans ce cas, l'authentification ne peut pas être effectuée. Par conséquent, même si la connexion en un clic est activée, elle doit toujours être compatible avec les méthodes de connexion traditionnelles, permettant aux utilisateurs de terminer normalement le processus de connexion en cas d'échec.
Après avoir appris et compris les 10 méthodes d'authentification ci-dessus, résumons brièvement
Authentification HTTP Basic convient aux réseaux internes ou aux réseaux qui n'ont pas d'exigences de sécurité très élevées HTTP 基本认证适用于内部网络，或者对安全要求不是很高的网络；Session-Cookie 适用于一般中大型的网站（移动端 APP 除外）；Token 和 JWT 都适用于市面上大部分的企业型网站，JWT 效能会优于 Token；单点登录 适用于子系统较多的大型企业网站；OAuth 2.0适用于需要快速注册用户型的网站；扫码登录 适用于已完成部署了三端的企业；一键登录Session-Cookie convient aux sites Web généraux de taille moyenne et grande ( applications mobiles sauf ); TokenetJWTconviennent à la plupart des sites Web d'entreprise du marché, et les performances de JWT seront meilleures que celles de TokenSingle Sign ; -On convient aux sites Web de grandes entreprises comportant de nombreux sous-systèmes ; <p></p> <code>OAuth 2.0convient aux sites Web qui doivent enregistrer rapidement des utilisateurs
Scannez le code QR pour vous connecter convient aux utilisateurs existants Entreprises qui ont terminé le déploiement de trois terminaux ; <a href="https://www.php.cn/course/list/1.html" target="_blank" textvalue="web前端"></a><code>Connexion en un clic convient aux applications natives
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
