身份验证（Authentication）是具备权限的系统验证尝试拜访零碎的用户或设施所用凭据的过程。相比之下，受权（Authorization）是给定系统验证是否容许用户或设施在零碎上执行某些工作的过程。
简略地说：
身份验证：你是谁？
受权：你能做什么？
身份验证先于受权。也就是说，用户必须先处于非法状态，而后能力依据其受权级别被授予对资源的拜访权限。验证用户身份的最常见办法是用户名和明码的组合。用户通过身份验证后，零碎将为他们调配不同的角色，例如管理员、主持人等，从而为他们授予一些非凡的零碎权限。
接下来，咱们来看一下用于用户身份验证的各种办法。
HTTP 根本验证
HTTP 协定中内置的根本身份验证（Basic auth）是最根本的身份验证模式。应用它时，登录凭据随每个申请一起发送到申请标头中：
“Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=” your-website.com
这里的用户名和明码未加密，而是应用一个: 符号将用户名和明码串联在一起，造成单个字符串：username:password，再应用 base64 编码这个字符串。
import base64
auth = “username:password”
auth_bytes = auth.encode(‘ascii’) # convert to bytes
auth_bytes
b’username:password’encoded = base64.b64encode(auth_bytes) # base64 encode
encoded
b’dXNlcm5hbWU6cGFzc3dvcmQ=’
base64.b64decode(encoded) # base64 decode
b’username:password’
这种办法是无状态的，因而客户端必须为每个申请提供凭据。它实用于 API 调用以及不须要长久会话的简略身份验证工作流。
流程
未经身份验证的客户端申请受限制的资源
返回的 HTTP401Unauthorized 带有标头 WWW-Authenticate，其值为 Basic。
WWW-Authenticate:Basic 标头使浏览器显示用户名和明码输入框
输出你的凭据后，它们随每个申请一起发送到标头中：Authorization: Basic dcdvcmQ=
长处
因为执行的操作不多，因而应用该办法能够疾速实现身份验证。
易于实现。
所有次要浏览器均反对。
毛病
Base64 不是加密。这只是示意数据的另一种形式。因为 base64 编码的字符串以纯文本格式发送，因而能够轻松解码。这么差的安全性很容易导致多种类型的攻打。因而，HTTPS/SSL 是相对必要的。
凭据必须随每个申请一起发送。
只能应用有效的凭据重写凭据来登记用户。
HTTP 摘要验证
HTTP Digest Auth（或 Digest Access Auth）是 HTTP 根本验证的一种更平安的模式。次要区别在于 HTTP 摘要验证的明码是以 MD5 哈希模式代替纯文本模式发送的，因而它比根本身份验证更平安。
流程
未经身份验证的客户端申请受限制的资源
服务器生成一个随机值（称为随机数，nonce），并发回一个 HTTP 401 未验证状态，带有一个 WWW-Authenticate 标头（其值为 Digest）以及随机数：WWW-Authenticate:Digestnonce=”44f0437004157342f50f935906ad46fc”
WWW-Authenticate:Basic 标头使浏览器显示用户名和明码输入框
输出你的凭据后，零碎将对明码进行哈希解决，而后与每个申请的随机数一起在标头中发送：Authorization: Digest username=”username”, nonce=”16e30069e45a7f47b4e2606aeeb7ab62″, response=”89549b93e13d438cd0946c6d93321c52″
服务器应用用户名获取明码，将其与随机数一起哈希，而后验证哈希是否雷同
长处
因为明码不是以纯文本模式发送的，因而比根本身份验证更平安。
易于实现。
所有次要浏览器均反对。
毛病
凭据必须随每个申请一起发送。
只能应用有效的凭据重写凭据来登记用户。
与根本身份验证相比，因为无奈应用 bcrypt，因而明码在服务器上的安全性较低。
容易受到中间人攻打。
基于会话的验证
应用基于会话的身份验证（或称会话 cookie 验证、基于 cookie 的验证）时，用户状态存储在服务器上。它不须要用户在每个申请中提供用户名或明码，而是在登录后由服务器验证凭据。如果凭据无效，它将生成一个会话，并将其存储在一个会话存储中，而后将其会话 ID 发送回浏览器。浏览器将这个会话 ID 存储为 cookie，该 cookie 能够在向服务器发出请求时随时发送。
基于会话的身份验证是有状态的。每次客户端申请服务器时，服务器必须将会话放在内存中，以便将会话 ID 绑定到关联的用户。
流程
http 会话身份验证工作流程
长处
后续登录速度更快，因为不须要凭据。
改善用户体验。
相当容易实现。许多框架（例如 Django）都是开箱即用的。
毛病
它是有状态的。服务器要在服务端跟踪每个会话。用于存储用户会话信息的会话存储须要在多个服务之间共享以启用身份验证。因而，因为 REST 是无状态协定，它不适用于 RESTful 服务。
即便不须要验证，Cookie 也会随每个申请一起发送
易受 CSRF 攻打。在这里浏览更多对于 CSRF 以及如何在 Flask 中进攻它的信息。
基于令牌的身份验证
这种办法应用令牌而不是 cookie 来验证用户。用户应用无效的凭据验证身份，服务器返回签名的令牌。这个令牌可用于后续申请。
最罕用的令牌是 JSON Web Token（JWT）。JWT 蕴含三个局部：
标头（包含令牌类型和应用的哈希算法）
负载（包含申明，是对于主题的陈说）
签名（用于验证音讯在此过程中未被更改）
这三局部都是 base64 编码的，并应用一个. 串联并做哈希。因为它们已编码，因而任何人都能够解码和读取音讯。然而，只有验证的用户能力生成无效的签名令牌。令牌应用签名来验证，签名用的是一个私钥。
JSON Web Token（JWT）是一种紧凑的、URL 平安的办法，用于示意要在两方之间转移的申明。JWT 中的申明被编码为一个 JSON 对象，用作一个 JSON Web Signature（JWS）构造的负载，或一个 JSON Web Encryption（JWE）构造的纯文本，从而使申明能够进行数字签名，或应用一个音讯验证码 Message Authentication Code（MAC）来做完整性爱护和 / 或加密。——IETF
令牌不用保留在服务端。只需应用它们的签名即可验证它们。近年来，因为 RESTfulAPI 和单页利用（SPA）的呈现，令牌的使用量有所增加。
流程
令牌验证工作流程
长处
它是无状态的。服务器不须要存储令牌，因为能够应用签名对其进行验证。因为不须要数据库查找，因而能够让申请更快。
实用于微服务架构，其中有多个服务须要验证。咱们只需在每一端配置如何解决令牌和令牌密钥即可。
毛病
依据令牌在客户端上的保留形式，它可能导致 XSS（通过 localStorage）或 CSRF（通过 cookie）攻打。
令牌无奈被删除。它们只能过期。这意味着如果令牌透露，则攻击者能够滥用令牌直到其到期。因而，将令牌过期工夫设置为十分小的值（例如 15 分钟）是十分重要的。
须要设置令牌刷新以在到期时主动发行令牌。
删除令牌的一种办法是创立一个将令牌列入黑名单的数据库。这为微服务架构减少了额定的开销并引入了状态。
一次性明码
一次性明码（One Time Password，OTP）通常用作身份验证的确认。OTP 是随机生成的代码，可用于验证用户是否是他们宣称的身份。它通常用在启用双因素身份验证的利用中，在用户凭据确认后应用。
要应用 OTP，必须存在一个受信赖的零碎。这个受信赖的零碎能够是通过验证的电子邮件或手机号码。
古代 OTP 是无状态的。能够应用多种办法来验证它们。只管有几种不同类型的 OTP，但基于工夫的 OTP（TOTP）能够说是最常见的类型。它们生成后会在一段时间后过期。
因为 OTP 让你取得了额定的一层平安爱护，因而倡议将 OTP 用于波及高度敏感数据的利用，例如在线银行和其余金融服务。
流程
实现 OTP 的传统形式：
客户端发送用户名和明码
通过凭据验证后，服务器会生成一个随机代码，将其存储在服务端，而后将代码发送到受信赖的零碎
用户在受信赖的零碎上获取代码，而后在 Web 利用上从新输出它
服务器对照存储的代码验证输出的代码，并相应地授予拜访权限
TOTP 如何工作：
客户端发送用户名和明码
通过凭据验证后，服务器会应用随机生成的种子生成随机代码，并将种子存储在服务端，而后将代码发送到受信赖的零碎
用户在受信赖的零碎上获取代码，而后将其输出回 Web 利用
服务器应用存储的种子验证代码，确保其未过期，并相应地授予拜访权限
谷歌身份验证器、微软身份验证器和 FreeOTP 等 OTP 代理如何工作：
注册双因素身份验证（2FA）后，服务器会生成一个随机种子值，并将该种子以惟一 QR 码的模式发送给用户
用户应用其 2FA 应用程序扫描 QR 码以验证受信赖的设施
每当须要 OTP 时，用户都会在其设施上查看代码，而后在 Web 利用中输出该代码
服务器验证代码并相应地授予拜访权限
长处
增加了一层额定的爱护
不会有被盗明码在实现 OTP 的多个站点或服务上通过验证的危险
毛病
你须要存储用于生成 OTP 的种子。
像谷歌验证器这样的 OTP 代理中，如果你失落了复原代码，则很难再次设置 OTP 代理
当受信赖的设施不可用时（电池耗尽，网络谬误等）会呈现问题。因而通常须要一个备用设施，这个设施会引入一个额定的攻打媒介。
**
OAuth 和 OpenID**
OAuth/OAuth2 和 OpenID 别离是受权和身份验证的风行模式。它们用于实现社交登录，一种单点登录（SSO）模式。社交登录应用来自诸如 Facebook、Twitter 或谷歌等社交网络服务的现有信息登录到第三方网站，而不是创立一个专用于该网站的新登录帐户。
当你须要高度平安的身份验证时，前端培训能够应用这种身份验证和受权办法。这些提供者中有一些领有足够的资源来加强身份验证能力。利用通过重复考验的身份验证零碎，能够让你的应用程序更加平安。
这种办法通常与基于会话的身份验证联合应用。
流程
你拜访的网站须要登录。你转到登录页面，而后看到一个名为“应用谷歌登录”的按钮。单击该按钮，它将带你到谷歌登录页面。通过身份验证后，你将被重定向回主动登录的网站。这是应用 OpenID 进行身份验证的示例。它让你能够应用现有帐户（通过一个 OpenID 提供程序）进行身份验证，而无需创立新帐户。
最驰名的 OpenID 提供方有谷歌、Facebook、Twitter 和 GitHub。
登录后，你能够转到网站上的下载服务，该服务可让你间接将大文件下载到谷歌云端硬盘。网站如何拜访你的 Google 云端硬盘？这里就会用到 OAuth。你能够授予拜访另一个网站上资源的权限。在这里，你授予的就是写入谷歌云端硬盘的拜访权限。
长处
进步安全性。
因为无需创立和记住用户名或明码，因而登录流程更加轻松快捷。
如果产生安全漏洞，因为身份验证是无明码的，因而不会对第三方造成侵害。
毛病
当初，你的应用程序依赖于你无法控制的另一个利用。如果 OpenID 零碎敞开，则用户将无奈登录。
人们通常偏向于疏忽 OAuth 应用程序申请的权限。
在你配置的 OpenID 提供方上没有帐户的用户将无法访问你的应用程序。最好的办法是同时实现多种路径。例如用户名和明码以及 OpenID，并让用户自行抉择。
总结
在本文中，咱们钻研了许多不同的 Web 身份验证办法，它们都有各自的优缺点。
你什么时候应该应用哪种办法？具体情况要具体分析。一些根本的教训法令：
对于利用服务端模板的 Web 应用程序，通过用户名和明码进行基于会话的身份验证通常是最合适的。你也能够增加 OAuth 和 OpenID。
对于 RESTful API，倡议应用基于令牌的身份验证，因为它是无状态的。
如果必须解决高度敏感的数据，则你可能须要将 OTP 增加到身份验证流中。
最初请记住，本文的示例仅仅是简略的演示。生产环境须要进一步的配置。