用户登录原理

常见认证方式

下面简述CS架构下系统常见的4种认证方式

基本认证

https://en.wikipedia.org/wiki/Basic_access_authentication
参考：RFC 7617

这种形式的授权不需要数据库、Cookie或会话来对用户进行身份验证，而是在现代浏览器中内置了身份验证系统，也可以称为基于浏览器的身份验证，由浏览器内置支持。

客户端和服务器的通信过程如下图所示：

1. 客户端请求服务器资源
2. 未认证的情况下，服务器在响应中发送HTTP状态代码401以及附加的HTTP标头WWW-Authenticate，其值为Basic，指示客户端应启动基本访问认证。

WWW-Authenticate : Basic

3. 当浏览器遇到上述响应头时，就会弹出登录窗口，其中包含用户名和密码的输入字段

访问地址http://httpbin.org/basic-auth/foo/bar，将看到一个提示，可以使用用户名foo和密码bar进行身份验证

4. 客户端在弹出窗口中提供用户名和密码的值，并提交表单。浏览器会使用base64编码对输入的用户名和密码进行编码，用冒号分隔，即Base64Encode('foo:bar')。例如，假设您输入用户名为foo，密码为bar，浏览器将按如下方式对其进行编码。

5. 浏览器客户端会在Authorization标头中发送编码的用户名和密码值。同时它还会在编码值之前添加字符串Basic，如下所示。
   

6. 服务器解码客户端在Authorization请求头中发送的用户名和密码，并将其与服务器上配置的有效用户名和密码进行比较。如果两个值匹配，则它将HTTP状态代码200与请求的数据一起发送。如果不正确，则服务器会按照步骤2中提到的WWW-Authenticate发送401，然后浏览器就会弹出登录框，像第 2 步那样

浏览器认证缓存

浏览器会自动记住登录的凭据并重用，一旦您成功通过身份验证，提示弹窗将停止出现（直到您下次关闭浏览器）。在大多数浏览器中，基本身份验证凭据不会与其他密码一起存储，不同浏览器清除缓存的方式也不同

令牌认证

基于令牌的身份验证是一种协议，允许用户验证身份，并获得唯一的访问令牌。在令牌的有效期内，用户可以访问已发行令牌的网站或应用程序，而不必每次回到同一网页、应用程序或受该令牌保护的任何资源时都重新输入凭据。令牌认证的工作原理就像盖章的票。只要令牌仍然有效，用户就可以保留访问权限。一旦用户注销或退出应用程序，令牌将失效。同时也可以对令牌设置过期时间，设置的时间一到自动失效

基于令牌的确认通常分为以下个阶段：

1. 客户端最开始未认证时通过用户名或密码来区分自己是合法用户
2. 服务端验证用户凭证，然后分发令牌，并且在服务端存储此令牌
3. 令牌由客户端持有，在每次访问服务器受保护的资源时都需要携带此令牌，服务端通过校验客户端的令牌和服务端的令牌来验证该用户是否已经认证成功过

OAuth 2.0认证

OAuth 是一个授权协议，通过授权码和访问令牌的方式进行多重验证来提供安全保证。OAuth 2.0 是其2.0版本

角色划分

OAuth 2.0 协议定义了四个角色：

1. 资源所有者（Resource Owner）：资源所有者是授权应用程序访问其帐户的用户。应用程序对用户帐户的访问仅限于授予的授权范围（例如读取或写入权限）
2. 客户端（Client）：客户端是想要访问用户帐户的应用程序。在这样做之前，必须由用户授权，并且授权必须由API验证
3. 资源服务器（Resource Server）：资源服务器托管受保护的用户帐户
4. 授权服务器（Authorization Server）：授权服务器验证用户的身份，然后向应用程序发放访问令牌
   从开发角度来看，单体应用的后台服务同时履行资源和授权服务器的角色。

交互流程如下图所示

1. 应用程序请求用户授权访问服务资源
2. 如果用户授权了该请求，则应用程序将收到授权码，授权码的用于获取令牌的标识
3. 应用程序通过提供其自身身份的身份验证和授权码，向授权服务器请求访问令牌。如果应用程序标识已通过身份验证并且授权码有效，则授权服务器将向应用程序颁发访问令牌。令牌存储在客户端
4. 应用程序需要提供用于身份验证的访问令牌从资源服务器请求资源
5. 资源服务器校验令牌的有效性，如果访问令牌有效，则资源服务器将资源提供给应用程序

API Key认证

API 密钥由随机生成的字母和数字字符组成。API 开发人员使用该字符串来控制对其 API 的访问权限可以将特定的 API 密钥与特定的 API 客户端相关联。由于 API 的使用本质上是一个软件模块与另一个软件模块通信，因此密钥与想要与 API 通信的不同软件模块或应用程序相关联。 常用在阿里云，华为云等云服务提供商对API的管理上。

工作流程如下所示：

1. API 服务器使用唯一的 API 密钥验证请求者的真实性
2. 如果 API 密钥与任何允许的密钥都不匹配，则服务器会拒绝 API 调用并发送拒绝消息
3. 如果 API 密钥匹配，服务器将履行请求并返回预期的响应
   这样，API 密钥就允许 API 服务器识别每个 API 调用的来源。然后，服务器可以执行后续验证，以授权访问 API 的数据和服务。

MFA认证

多因子认证MFA（Multi Factor Authentication）是一种安全认证过程，需要用户提供两种及以上不同类型的认证因子来表明自己的身份，包括密码、指纹、短信验证码、智能卡、生物识别等多种因素组合，从而提高用户账户的安全性和可靠性。

为什么使用MFA?
单一的验证方式防御较为薄弱，存在一定风险，比如密码会存在“暴力破解”、“撞库”、钓鱼邮件等攻击风险。钥匙、门卡面临丢失、被盗的可能。而生物特征，一旦遭遇信息泄漏，则面临更大的威胁。

常见的身份认证因子分类有：

1. 秘密信息因子，包含密码、个人身份识别码 (PIN) 、安全问题验证。
2. 物品因子，分为软件令牌和硬件令牌。
   软件令牌，包含短信验证码，电子邮件验证链接、验证码，服务商提供的身份验证二维码（例如微信扫码认证）。
   硬件令牌，包含身份证、驾驶证、护照、密钥卡、硬件加密锁等专用物品作为安全密钥使用 。
3. 生物特征因子，包含指纹、语音、面部特征、虹膜、视网膜图案、DNA、个人手写签名、击键特征和语言模式等行为生物识别特征。
4. 位置因子，包含特定位置、特定设备、特定IP范围。
5. 时间因子，特定的时间段。

如果多个身份认证方式为一种身份认证因子类型，此认证方式为单因子认证，而不是多因子认证。例如用户密码+安全问题验证、身份证+短信验证码+电子邮件验证链接等，均为单因子认证。多因子认证必须是两种及以上不同类型的认证因子，来实现用户身份认证。

认证流程

用户登录应用程序、服务、网络设备系统时，MFA认证流程原理都相同。下面以应用程序的MFA认证流程为例：

1. 用户登录应用程序。
2. 用户输入登录凭证，通常是账号和密码，做初始身份验证。
3. 验证成功后，然后将提示用户提交第二个身份验证因子。
4. 用户将第二个身份验证因子输入至应用程序，做二次身份验证。
5. 如果系统只设置了两种因子认证，第二个身份验证因子通过，用户将通过身份验证并被授予对应的系统操作权限。如果系统设置了三种及以上种因子认证，用户需按系统提示，继续提交身份信息，直至全部身份因子验证通过，并被授予对应的系统操作权限。

单点登录 SSO

效果就是允许用户只登录一次即可访问多个应用程序或系统，从而提高用户体验和工作效率。

基本原理

SSO通常用一个身份验证服务提供商IdP（Identity Provider）来管理用户的身份验证信息，并将这些信息传递给需要身份验证的应用程序或系统。用户只需进行一次身份验证，就可以访问受保护的资源，无需再次输入凭据。

1. 用户首次访问一个需要身份验证的应用程序或系统。
2. 应用程序或系统将用户重定向到IDP，用户在IDP上进行身份验证，通常是输入用户名和密码。
3. IdP向用户颁发令牌Token，该令牌包含有关用户身份验证的信息。
4. 用户被重定向回原始的应用程序或系统，并将令牌传递给该应用程序或系统，应用程序或系统使用令牌来验证用户身份，并授予用户访问权限。
5. 如果用户访问其他需要身份验证的应用程序或系统，该应用程序或系统将使用相同的令牌到IDP进行用户身份验证。

第三方授权登录

通过第三方平台登录本系统，而无需知道第三方系统的用户名和密码。这种登录方式不仅简化了用户的注册和登录流程，还提高了安全性和隐私保护水平。

登录流程

第三方登录的原理基于OAuth授权协议，通过授权码、Access Token等机制实现用户身份的验证和资源的访问。

1. 首先用户在客户端（如网站或应用）上选择使用第三方平台（如微信、QQ、GitHub等）进行登录，选择后会跳转到第三方的登录页面

比如CSDN选择QQ登录，是打开了一个新的弹窗，访问的页面地址就是qq的登录地址

把这个地址单独拿出来看：
https://graph.qq.com/oauth2.0/show?which=Login&display=pc&client_id=100270989&response_type=code&redirect_uri=https%3A%2F%2Fpassport.csdn.net%2Faccount%2Flogin%3FpcAuthType%3Dqq%26newAuth%3Dtrue%26state%3Dtest

在请求的地址上会通过url参数的形式传递如果登录成功后跳转的地址

2. 用户向客户端提供第三方平台的登录数据（用户名，密码），登陆成功后客户端将用户重定向到第三方平台的授权页面。

这个跳转操作是由qq服务器那边进行重定向本次请求实现的，然后客户端这边会请求重定向的地址，即传递的参数里填入的重定向地址

https://passport.csdn.net/account/login?pcAuthType=qq&newAuth=true&state=test

直接访问这个地址，会返回302

3. 获取授权码：
   用户在第三方平台上进行身份验证，并同意授权客户端访问其资源。第三方平台生成一个授权码，并将其发送回客户端的回调URL。
   交换授权码获取Access Token：
   客户端收到授权码后，使用申请的项目中的AppID和密钥以及授权码，向第三方平台的授权服务器请求Access Token。

4. 授权服务器验证授权码的合法性，如果通过验证，则颁发Access Token给客户端。

客户端使用Access Token向第三方平台的资源服务器请求用户资源（如头像、昵称、性别等）。
资源服务器验证Access Token的有效性，如果通过验证，则返回用户资源给客户端。

5. 完成登录或注册：
   客户端根据获取到的用户资源，完成在当前项目下的登录或注册流程。

安全性与隐私保护

1. 在第三方登录过程中，用户的用户名和密码从未直接传递给客户端或第三方应用，而是通过OAuth授权协议进行安全地交换和验证。
2. 第三方平台通常会提供严格的隐私保护措施，确保用户的个人信息不会被滥用或泄露。

扫码登陆

现在扫码登录是一种很常见的登录方式。当用户需要登录某个网站时，网站会提供一种扫码登录的方式，用户打开相应的手机App，扫描网站上显示的二维码，然后在App中确认登录，网站监测到用户确认登录后，跳转到登录成功页面。

扫码登录就是将用户在手机App中的登录状态同步到PC端。如下图所示，整个过程比较简单，这里大概分为如下几个步骤：

1. 二维码登录时，网站服务端会先生成一个二维码，同时把这个二维码对应的标识保存起来，以便跟踪二维码的扫码状态，然后将二维码页面返回给浏览器；浏览器先展示这个二维码，再发起扫码状态轮询，即浏览器每隔几秒调用服务端API查询二维码的扫码登录结果，查询时携带二维码的标识
2. 用户扫码确认登录：用户打开手机App，使用App自带的扫码功能，扫描浏览器中展现的二维码，然后App提取出二维码中的登录信息，显示登录确认的页面，这个页面可以是App的Native页面，也可以是远程H5页面，这里采用Native页面，用户点击确认或者同意按钮后，App将二维码信息和当前用户的Token一起提交到网站API，网站API确认用户Token有效后，更新在步骤1中创建的二维码标识的状态为“确认登录”，同时绑定当前用户。
3. 网站验证登录成功：在步骤1中，二维码登录页面启动了一个扫码状态的轮询，如果用户已经“确认登录”，则轮询访问网站API时，网站会生成二维码绑定用户的登录Session，然后向前端返回登录成功消息。

为了保证登录的安全，有必要采取一些安全措施，例如：

1. 对二维码承载的信息按照某种规则进行处理，App可以在扫码时进行验证，避免任何扫码都去请求登录；
2. 对二维码设置一个过期时间，过期就自动删除，这样使其占用的资源保持在合理范围之内；
3. 限制二维码只能使用一次，防止重放攻击；
4. 二维码使用足够长的随机性字符串，防止被恶意穷举占用；
5. 使用HTTPS传输，保护登录数据不被窃听和篡改。

扫码状态轮询为什么不使用WebSocket

虽然WebSocket响应比较及时，但是从兼容性和复杂度考虑，大部分方案还是会选择轮询或者长轮询，毕竟此时通信稍微延迟下也没多大关系。