身份验证（Authentication）是通过授权系统验证试图访问系统的用户或设备的凭据的过程。相比之下，授权是给定系统验证用户或设备是否被允许在系统上执行某些任务的过程。简单地说：身份验证：你是谁？赋权：你能做什么？身份验证先于授权。也就是说，用户必须处于合法状态才能根据其授权级别被授予对资源的访问权限。验证用户身份的最常见方法是用户名和密码组合。用户通过认证后，系统会为其分配不同的角色，如管理员、版主等，从而授予他们一些特殊的系统权限。接下来，让我们看看用于用户身份验证的各种方法。HTTP基本认证HTTP协议内置的基本认证（Basicauth）是最基本的认证形式。使用它时，登录凭据随请求标头中的每个请求一起发送：“授权：基本dXNlcm5hbWU6cGFzc3dvcmQ=”your-website.com这里的用户名和密码未加密，而是用:符号连接在一起，形成一个单个字符串：username:password，然后使用base64对这个字符串进行编码。importbase64auth="username:password"auth_bytes=auth.encode('ascii')#转换为bytesauth_bytesb'username:password'encoded=base64.b64encode(auth_bytes)#base64encodeencodedb'dXNlcm5hbWU6cGFzc3dvcmQ='base64.b64d64decode(decodeb'用户名:password'此方法是无状态的，因此客户端必须为每个请求提供凭据。它适用于API调用和不需要持久会话的简单身份验证工作流程。请求受限资源的未经身份验证的客户端进程返回HTTP401Unauthorized标头WWW-使用Basic值进行身份验证。WWW-Authenticate:Basic标头使浏览器显示用户名和密码输入框。输入您的凭据后，它们将在标头中与每个请求一起发送：Authorization:BasicdcdvcmQ=Advantage由于它没有做太多，使用此方法可以快速完成身份验证。易于实施。支持所有主要浏览器。缺点Base64不加密。这只是表示数据的另一种方式。由于base64编码的字符串以明文形式发送，因此很容易被解码。如此糟糕的安全性很容易引发多种类型的攻击。因此，HTTPS/SSL是绝对必要的。每个请求都必须发送凭据。只能通过使用无效凭据覆盖凭据来注销用户。HTTP摘要身份验证HTTP摘要身份验证（或摘要访问身份验证）是一种更安全的HTTP基本身份验证形式。主要区别在于HTTP摘要式身份验证的密码以MD5哈希而不是纯文本形式发送，因此它比基本身份验证更安全。Process未经身份验证的客户端请求受限资源服务器生成一个随机值（称为随机数）并发回带有WWW-Authenticate标头（值为Digest）和随机数的HTTP401未经身份验证状态：WWW-Authenticate:Digestnonce="44f0437004157342f50f935906ad46fc"WWW-Authenticate:Basicheader使浏览器显示用户名和密码输入框输入您的凭据后，对密码进行哈希处理，然后与nonce一起发送到header:Authorization:Digestusername="username",nonce="16e30069e45a7f47b4e2606aeeb7ab62",response="89549b93e13d438cd0946c6d93321c52"服务器使用用户名获取密码，用随机数对其进行哈希处理，并验证该哈希值是否相同优点比基本身份验证更安全，因为密码不是以纯文本形式发送的。易于实施。支持所有主要浏览器。缺点凭据必须随每个请求一起发送。只能通过使用无效凭据覆盖凭据来注销用户。与基本身份验证相比，由于无法使用bcrypt，密码在服务器上的安全性较低。容易受到中间人攻击。基于会话的身份验证使用基于会话的身份验证（或会话cookie身份验证，基于cookie的身份验证），用户状态存储在服务器上。它不需要用户为每个请求提供用户名或密码，而是服务器在登录后验证凭据。如果凭据有效，它会生成一个会话，将其存储在会话存储中，并将其会话ID发送回浏览器。浏览器将此会话ID存储为cookie，可以在向服务器发出请求时随时发送。基于会话的身份验证是有状态的。每次客户端向服务器发出请求时，服务器必须将会话保存在内存中，以便将会话ID绑定到关联的用户。Processhttpsessionauthenticationworkflowadvantages后续登录速度更快，因为不需要凭据。改善用户体验。很容易实现。许多框架（例如Django）都带有开箱即用的功能。缺点是它是有状态的。服务器跟踪服务器端的每个会话。用于存储用户会话信息的会话存储需要在多个服务之间共享以启用身份验证。因此，由于REST是无状态协议，不适合RESTful服务。即使不需要身份验证，每个请求都会发送Cookie易受CSRF攻击。在此处阅读有关CSRF以及如何在Flask中防御它的更多信息。基于令牌的身份验证此方法使用令牌而不是cookie来对用户进行身份验证。用户使用有效凭据进行身份验证，服务器返回签名令牌。此令牌可用于后续请求。最常用的令牌是JSONWeb令牌(JWT)。JWT由三部分组成：Header（包括token类型和使用的哈希算法）Payload（包括claims，是关于主题的声明）Signature（用于验证消息在处理过程中没有被更改）这三部分都是base64编码的,连接一个.和散列。由于它们是经过编码的，因此任何人都可以解码和阅读消息。但是，只有经过身份验证的用户才能生成有效的签名令牌。使用签名验证令牌，并使用私钥签名。JSONWebToken(JWT)是一种紧凑的、URL安全的方式来表示要在两方之间传输的声明。JWT中的声明被编码为JSON对象，用作JSONWeb签名(JWS)结构的有效负载，或作为JSONWeb加密(JWE)结构中的纯文本，允许对声明进行数字签名或使用验证用于完整性保护和/或加密的消息代码消息验证代码(MAC)。-IETF令牌不必存储在服务器端。只需使用他们的签名来验证他们。近年来，由于RESTfulAPI和单页应用程序(SPA)的出现，令牌的使用有所增加。ProcessTokenValidationWorkflow优势它是无状态的。服务器不需要存储令牌，因为它可以使用签名进行验证。这使得请求更快，因为不需要数据库查找。适用于需要验证多个服务的微服务架构。我们只是在每一端配置如何处理令牌和令牌秘密。缺点根据令牌在客户端的保存方式，它可能导致XSS（通过localStorage）或CSRF（通过cookie）攻击。无法删除令牌。它们只能过期。这意味着如果令牌泄漏，攻击者可以滥用令牌直到它过期。因此，将令牌过期时间设置为一个非常小的值（例如15分钟）非常重要。令牌刷新需要设置为在令牌过期时自动发放令牌。删除令牌的一种方法是创建一个列入黑名单的令牌数据库。这会增加额外的开销并将状态引入微服务架构。一次性密码一次性密码(OTP)通常用作身份验证确认。OTP是随机生成的代码，可用于验证用户是否是他们声称的身份。它通常用于在确认用户凭据后启用双因素身份验证的应用程序。要使用OTP，必须存在受信任的系统。这个可信系统可以是经过验证的电子邮件或手机号码。现代OTP是无状态的。可以使用各种方法验证它们。虽然有几种不同类型的OTP，但基于时间的OTP(TOTP)可以说是最常见的。它们在生成后的一段时间后过期。由于OTP为您提供额外的安全层，因此建议将OTP用于涉及高度敏感数据的应用程序，例如网上银行和其他金融服务。该过程实现了OTP的传统方式：客户端发送用户名和密码，经过凭证验证后，服务器生成一个随机代码，存储在服务器上，然后将代码发送到受信系统。用户在受信任的系统上获取代码，然后在网络应用程序上重新输入该代码服务器根据存储的代码验证输入的代码并相应地授予访问权限TOTP的工作原理：客户端发送用户名和密码验证凭据后，服务器生成使用随机生成的种子的随机代码，并将种子存储在服务器端，然后将代码发送到受信任的系统用户在受信任的系统上获取代码并将其输入回Web应用程序服务器使用存储的种子进行验证代码，确保它没有过期，并做出相应响应OTP代理（如GoogleAuthenticator、MicrosoftAuthenticator和FreeOTP）如何工作：注册双因素身份验证(2FA)后，服务器生成一个随机种子值并发送该值种子作为唯一的QR码给用户用户使用他们的2FA应用程序扫描QR码以验证受信任的设备每当需要OTP时，用户检查他们设备上的代码并将其输入Web应用程序服务器验证代码并授予相应地访问优点添加额外的保护层没有密码被盗的危险在实施OTP的多个站点或服务上验证缺点您需要存储用于生成OTP的种子。在像GoogleAuthenticator这样的OTP代理中，如果您丢失了恢复代码，则很难再次设置OTP代理当受信任的设备不可用时（电池耗尽、网络错误等），就会出现问题。因此通常需要备用设备，这会引入额外的攻击媒介。**OAuth和OpenID**OAuth/OAuth2和OpenID分别是流行的授权和身份验证形式。它们用于实现社交登录，这是一种单点登录(SSO)形式。社交登录使用来自社交网络服务（例如Facebook、Twitter或Google）的现有信息来登录第三方网站，而不是创建专用于该网站的新登录帐户。前端培训在需要高度安全的认证时可以使用这种认证授权方式。其中一些提供商拥有足够的资源来增强身份验证功能。利用久经考验的身份验证系统使您的应用程序更加安全。这种方法通常与基于会话的身份验证结合使用。流程您访问的网站需要登录。您转到登录页面并看到一个名为“使用Google登录”的按钮。单击该按钮，它将带您到Google登录页面。一旦通过身份验证，您将被重定向回自动登录的网站。下面是一个使用OpenID进行身份验证的示例。它允许您使用现有帐户（通过OpenID提供商）进行身份验证，而无需创建新帐户。最著名的OpenID提供商是Google、Facebook、Twitter和GitHub。登录后，您可以转到网站上的下载服务，该服务允许您将大文件直接下载到GoogleDrive。网站如何访问您的Google云端硬盘？这里将使用OAuth。您可以授予对其他网站上资源的访问权限。在这里，您授予的是对Google云端硬盘的写入权限。优点增加安全性。由于无需创建和记住用户名或密码，因此登录过程更加简单快捷。如果出现安全漏洞，则不会对第三方造成伤害，因为身份验证是无密码的。缺点现在，您的应用程序依赖于您无法控制的另一个应用程序。如果OpenID系统宕机，用户将无法登录。人们往往会忽略OAuth应用程序请求的权限。没有您配置的OpenID提供商帐户的用户将无法访问您的应用程序。最好的方法是同时实施多条路径。比如用户名密码和OpenID，让用户选择。总结在本文中，我们研究了多种不同的Web身份验证方法，每种方法各有优缺点。什么时候应该使用哪种方法？具体情况要具体分析。一些基本的经验法则：对于使用服务器端模板的Web应用程序，通过用户名和密码进行的基于会话的身份验证通常是最合适的。您还可以添加OAuth和OpenID。对于RESTfulAPI，建议使用基于令牌的身份验证，因为它是无状态的。如果您必须处理高度敏感的数据，则可能需要将OTP添加到身份验证流程中。最后，请记住本文中的示例只是演示。生产环境需要进一步配置。
