1、Token
1.1、 什么是Token?
token的意思是"令牌",是服务端生成的一串字符串,作为客户端进行请求的一个标识。
Token验证是一种身份验证机制,用于验证用户或客户端的身份。在计算机系统中,Token是一个包含有关用户身份信息的字符串。当用户进行身份验证时,系统会颁发一个Token给用户,然后用户在后续的请求中使用该Token进行身份验证。
(简单来说:当用户第一次登录后,服务器生成一个token并将此token返回给客户端,以后客户端只需带上这个token前来请求数据即可,无需再次带上用户名和密码。)
1.2、为什么要用Token?
- Token 完全由应用管理,所以它可以避开同源策略
- Token 可以避免 CSRF 攻击
- Token 可以是无状态的,可以在多个服务间共享
- 基于token机制的身份认证
- 使用token机制的身份验证方法,在服务器端不需要存储用户的登录记录。
- 无需在每个请求中发送用户名和密码,减少了传输的安全风险。
- Token可以设置过期时间,提高了安全性。
大概的流程:
- 客户端使用用户名和密码请求登录。
- 服务端收到请求,验证用户名和密码。
- 验证成功后,服务端会生成一个token,然后把这个token发送给客户端。
- 客户端收到token后把它存储起来,可以放在cookie或者Local Storage(本地存储)里。用户在后续的请求中将该Token作为身份验证凭据发送给系统。
- 客户端每次向服务端发送请求的时候都需要带上服务端发给的token。
- 服务端收到请求,然后去验证客户端请求里面带着token,系统接收到请求后,会检查Token的有效性。如果Token有效,则表示用户已经通过身份验证。如果验证成功,系统决定是否允许用户执行请求的操作,就向客户端返回请求的数据。(如果这个 Token 在服务端持久化(比如存入数据库),那它就是一个永久的身份令牌。)
Token需要设置有效期吗?
- 一个例子是登录密码,一般要求定期改变密码,以防止泄漏,所以密码是有有效期的;
- 另一个例子是安全证书。SSL 安全证书都有有效期,目的是为了解决吊销的问题。
所以无论是从安全的角度考虑,还是从吊销的角度考虑,Token 都需要设有效期。
1.3、Token和Cookie的区别是什么?
Token是一种在客户端和服务器之间传递身份信息的机制,可以存储在Cookie中或通过其他方式进行传递。
Cookie是一种在客户端存储数据的机制,用于在浏览器和服务器之间传递数据。
它们之间的区别如下:
1、存储位置:
- Token通常存储在客户端,可以存储在内存中、本地存储(如localStorage)或浏览器的Cookie中。
- Cookie存储在客户端的浏览器中,作为HTTP请求的一部分自动发送给服务器。
2、数据内容:
- Token是一个包含有关用户身份和权限信息的字符串,通常使用加密算法进行签名和验证。
- Cookie是由服务器设置在客户端浏览器中的键值对数据,可以存储用户的身份信息、会话标识符和其他应用程序状态。
3、安全性:
- Token可以使用加密算法和数字签名进行验证,以确保其完整性和安全性。
- Cookie的安全性较低,可以设置为HttpOnly属性来限制JavaScript的访问,但仍然容易受到跨站脚本攻击(XSS)和跨站请求伪造(CSRF)等攻击方式的威胁。
4、扩展性:
- Token验证适用于分布式系统和API身份验证,可以在不同的服务之间进行传递和验证。
- Cookie通常与特定的域名关联,只能在同一域名下使用,不太适用于跨域场景。
5、无状态性:
- Token验证是无状态的,服务器不需要在后端存储用户的会话信息,每个请求都包含足够的信息进行身份验证。
- Cookie验证是有状态的,服务器需要在后端存储和管理会话信息,以便识别和跟踪用户的状态。
2、单点登录
2.1、什么是单点登录(SSO)?
单点登录(Single Sign-On,简称SSO)是一种身份验证机制,指在同一帐号平台下的多个应用系统中,用户只需登录一次,即可访问所有相互信任的系统。简而言之,多个系统,统一登陆。
(允许用户在一次登录后,通过一组凭据(如用户名和密码)访问多个相关应用程序或系统,而无需为每个应用程序都重新输入凭据。)
传统登录流程图:

单点登录流程图:

例子:

新浪微博与新浪博客是相互信任的应用系统:
- 当用户首次访问新浪微博时,新浪微博识别到用户未登录,将请求重定向到认证中心,认证中心也识别到用户未登录,则将请求重定向到登录页。
- 当用户已登录新浪微博访问新浪博客时,新浪博客识别到用户未登录,将请求重定向到认证中心,认证中心识别到用户已登录,返回用户的身份,此时用户无需登录即可使用新浪博客。
- 只要多个系统使用同一套单点登录框架那么它们将是相互信任的。
2.2、单点登录原理
sso需要一个独立的认证中心,所有子系统都通过认证中心的登录入口进行登录,登录时带上自己的地址,子系统只接受认证中心的授权,授权通过令牌(token)实现,sso认证中心验证用户的用户名密码正确,创建全局会话和token,token作为参数发送给各个子系统,子系统拿到token,即得到了授权,可以借此创建局部会话,局部会话登录方式与单系统的登录方式相同。



2.3、介绍一下登录的实现方案
1.通过 cookie 进行验证
cookie 是某些网站为了辨别用户身份,由服务端生成,发给客户端暂时或永久保存的信息。简言之,cookie 就是一种存储用户数据的媒介。举例来说,当我们打开一个网站,比如新浪、CSDN、知乎时,输入用户名和密码登录后系统会弹出是否保存 cookie,如果我们选择保存,在下一次登录时,就不需要再次输入用户名和密码,而是默认登录成功,直接进入页面。

2.通过 session 进行验证
就是服务器为了储存用户信息而创建的一个验证手段。用户在登录了一个系统后,服务器会将登录信息储存在一个 session 中,产生 session ID,客户端会保存该 ID;当这个用户再登录其他系统时,服务器会自动复制上一个模块的 session 该服务器的 session 中,以获取用户登录信息,实现用户只登录一次,就可以登录其他系统。在用户退出登录时,服务器会自动删除 session。
整个过程均在服务器端完成,用户实际使用时没有感知。

3.使用token实现
token 在身份认证中是令牌的意思,在词法分析中是标记的意思。一般作为邀请、登录系统使用。简言之,token 就是一种凭证,用户在登录注册时需要获取凭证,在经过验证后,方可登录相关被授权的应用。
用户在首次登录系统时输入账号和密码,服务器会收到登录请求,然后验证是否正确;
服务器会根据用户信息,如用户 ID、用户名、秘钥、过期时间等信息生成一个 token 签名,然后发给用户;
用户验证成功后,返回 token;
前端服务器收到 token 后,存储到 cookie 或 Local Storage 里; 当用户再次登录时,会被服务器验证 token;
服务器收到用户登录请求后,对 token 签名进行比对:如果 token 验证正确,用户登录成功;如果 token 验证不正确,用户登录失败,跳转到登录页。

4.通过页面重定向的方式
最后一种介绍的方式,是通过父应用和子应用来回重定向中进行通信,实现信息的安全传递。 父应用提供一个GET方式的登录接口,用户通过子应用重定向连接的方式访问这个接口,如果用户还没有登录,则返回一个的登录页面,用户输入账号密码进行登录。如果用户已经登录了,则生成加密的Token,并且重定向到子应用提供的验证Token的接口,通过解密和校验之后,子应用登录当前用户。
这种方式较前面两种方式,接解决了上面两种方法暴露出来的安全性问题和跨域的问题,但是并没有前面两种方式方便。 安全与方便,本来就是一对矛盾。
2.4、前端登录方式详解:Cookie + Session、Token、SSO与OAuth的比较与选择
登录是多数网站都有的功能,这里面也涉及到很多问题和知识。常见的登录方式有以下几种:Cookie + Session 登录、Token 登录、SSO 单点登录和 OAuth 第三方登录。下面就来学习一下这些登录方式。
一、Cookie + Session 登录
- 概述
Cookie + Session 是一种历史悠久的登录方式,通过在客户端存储用户信息(Cookie),并在服务器端管理用户会话(Session),实现用户的登录状态管理。 - 实现流程
(1)用户输入用户名和密码,点击登录按钮;
(2)前端将用户名和密码发送到后端;
(3)后端验证用户名和密码是否正确;
(4)如果验证通过,后端创建一个 Session,并将 Session ID 存储到 Cookie 中;
(5)前端每次请求时,会将 Cookie 发送到后端;
(6)后端根据 Cookie 中的 Session ID 找到对应的 Session,从而识别用户身份。 - 特点
(1)简单易用,适合简单的后端架构;
(2)需要开发人员自己处理好安全问题,如加密用户密码、设置 Cookie 的 HttpOnly 属性等;
(3)服务器端需要对接大量的客户端,导致服务器压力较大;
(4)存在 CSRF 攻击的风险。
二、Token 登录
- 概述
Token 登录是一种基于令牌的身份验证方式,用户通过登录认证后,服务器会生成一个 Token,并返回给客户端,客户端后续请求时携带该 Token 进行身份验证。 - 实现流程
(1)用户输入用户名和密码,点击登录按钮;
(2)前端将用户名和密码发送到后端;
(3)后端验证用户名和密码是否正确;
(4)如果验证通过,后端生成一个 Token,并将该 Token 返回给前端;
(5)前端将 Token 存储到本地(如 LocalStorage),并在每次请求时携带该 Token;
(6)后端根据请求中的 Token 进行身份验证。 - 特点
(1)减少服务器压力,提高性能;
(2)客户端存储 Token,更加安全;
(3)支持跨域请求;
(4)需要开发人员自己设计 Token 的生成和管理方式,以及防止重复登录等问题。
三、SSO 单点登录
- 概述
SSO 单点登录是一种集中式身份验证方式,多个应用共享同一个身份验证系统,用户在任意一个应用登录后,其他应用都能获取到该用户的登录状态。 - 实现流程
(1)用户在任何一个应用中输入用户名和密码进行登录;
(2)应用将用户信息发送到 SSO 服务器进行验证;
(3)SSO 服务器验证用户信息并返回一个票据(Ticket);
(4)应用将票据存储到本地,并在后续请求中携带该票据;
(5)SSO 服务器根据票据识别用户身份,返回用户信息。 - 特点
(1)适用于中大型企业,方便统一管理内部所有应用的登录方式;
(2)提高用户体验,用户在任意一个应用中登录后,其他应用都能自动获取到该用户的登录状态;
(3)需要开发人员处理票据的生成和管理,以及防止重复登录等问题。
四、OAuth 第三方登录
- 概述
OAuth 第三方登录是一种基于授权的登录方式,用户通过授权第三方应用访问自己的账号信息,而不需要将用户名和密码泄露给第三方应用。 - 实现流程
(1)用户在第三方应用中选择登录按钮,并跳转到 OAuth 授权页面;
(2)OAuth 授权页面显示用户授权列表,用户选择要授权的应用;
2.5、在前端应用中实现单点登录可以遵循以下步骤:
- 选择合适的SSO协议:选择与你的前端应用程序兼容的SSO协议。常见的SSO协议包括SAML(Security Assertion Markup Language)、OAuth和OpenID Connect等。每个协议都有其特定的使用场景和实现方式,需要根据应用程序的需求选择合适的协议。
- 集成认证服务提供者(Identity Provider,简称IdP):与一个或多个认证服务提供者集成,作为身份验证和令牌颁发的中心。认证服务提供者负责管理用户身份和凭据,验证用户的登录请求,并颁发令牌。
- 配置前端应用程序:根据选择的SSO协议和认证服务提供者的要求,配置前端应用程序以接收和处理认证请求。这可能包括配置回调URL、注册应用程序以获得客户端ID和密钥等。
- 实现认证流程:在前端应用程序中,根据选择的SSO协议和协议规范,实现认证流程。这通常涉及将用户重定向到认证服务提供者的登录页面,用户提供凭据进行身份验证,并接收并验证认证服务提供者返回的令牌。
- 处理令牌和身份验证:在前端应用程序中,根据协议规范处理和存储认证服务提供者返回的令牌。这可能涉及解码和验证令牌的签名、提取用户身份信息以及将用户身份信息与应用程序的用户系统进行关联。
- 跨应用程序会话管理:通过SSO机制,用户在进行认证后可以访问多个应用程序,因此需要实现会话管理来跨应用程序共享登录状态。这可以通过在前端应用程序中存储令牌、在每个应用程序间共享令牌或使用会话管理工具(如共享会话存储或令牌中心)来实现。
需要注意的是,具体的SSO实现方式取决于所选择的协议和认证服务提供者。在实施SSO之前,确保对所选协议和相关文档有充分的了解,并遵循最佳实践和安全性要求。
另外,前端应用程序的SSO实现通常需要与后端服务器进行协作。后端服务器可能需要验证和解析令牌,并与认证服务提供者进行通信以确保令牌的有效性。因此,与后端开发团队合作,确保前端应用程序和后端服务器之间的集成和通信是关键的。
总结起来,在前端应用程序中实现单点登录的关键步骤包括选择合适的SSO协议、集成认证服务提供者、配置应用程序、实现认证流程、处理令牌和身份验证,以及跨应用程序会话管理。这些步骤可能因所选协议和认证服务提供者的不同而有所差异,因此需要仔细了解相关文档和规范,并与后端开发团队密切合作以确保成功实现单点登录功能。