伴侣，您如何进行身份验证？

权威的软件开发人员认证指南

我们都知道在我们的应用程序中认证用户的通用过程。 这是一种古老的方法，即用用户的基本信息（例如电子邮件，密码等）注册用户，然后在登录时，将给定的电子邮件，密码与先前存储的数据进行匹配。 如果匹配，则允许他/她访问，否则不访问。

但是时间已经改变，并且随着时间的推移引入了许多其他身份验证方法。 为了在这个瞬息万变，不断变化的软件开发世界中，使自己作为程序员/开发人员有价值，您需要了解这些新方法。

不可否认的事实是，“身份验证”在任何类型的应用程序或系统中至关重要，以确保用户数据的安全和对信息的正确访问。 要确定哪种身份验证方法更适合您，将需要有关身份验证方法，它们之间的权衡以及大多数情况下它们如何工作的知识。

在这里，我将尝试向您介绍这几天使用的最常见和最受欢迎的身份验证方法。 这不会是这些方法的详细技术指南，而只是使您熟悉它们的一种尝试。 尽管在讨论以下主题时考虑到了“网络”，但是这些概念不仅限于此。 这些概念和方法在其他领域也可以证明是有用的。

我将继续我的文章，假设您已经知道一个事实，即大多数网络/互联网（如我们所知）都是基于HTTP协议构建的。 同样，在继续之前，您应该已经知道Web应用程序的工作方式，通过向该应用程序验证用户身份意味着什么以及什么是客户端-服务器体系结构。

准备好旅途了吗？ 潜水吧

基于会话的身份验证：

由于HTTP协议 是无状态的 ，因此这意味着如果我们使用用户名和密码对用户进行身份验证，则在下一个请求时，我们的应用程序将不会知道此人与上一个请求是同一个人。 我们将不得不再次进行身份验证。 对于每个请求，HTTP都不了解之前发生的事情，它只是承载请求。 因此，对于任何对私人数据的请求，您都必须再次登录以确保应用程序知道这确实是您。 这会很烦人。

为避免此问题，引入了基于会话/ cookie的身份验证。 它使身份验证过程“有状态” ，这意味着必须同时在服务器端和客户端保留身份验证记录或会话。 服务器需要跟踪数据库或内存中的活动会话，而在前端则创建一个cookie，其中包含一个会话标识符，从而基于名称cookie进行身份验证。 这是最常用的认证方法，已经使用了很长时间。

基于会话的身份验证的基本流程：

1. 在浏览器中，用户输入用户名和密码，请求从客户端应用程序发送到服务器。
2. 服务器检查用户，对其进行身份验证，然后将唯一令牌发送到用户的客户端应用程序。 （还将此唯一令牌保存在内存或数据库中）
3. 客户端应用程序将令牌存储在cookie中，然后将其与每个后续请求一起发送回去。
4. 服务器接收每个需要身份验证的请求，并使用令牌对用户进行身份验证，然后将请求的数据返回给客户端应用程序。
5. 当某人注销时，客户端应用程序会删除该令牌，因此客户端对Rails的后续请求将变得未经授权。

图片来源： auth0博客

这种身份验证方法引起了一些主要问题。

• 每次对用户进行身份验证时，服务器将需要在服务器上的某处创建一条记录。 这通常在内存中完成，并且当有许多用户进行身份验证时，服务器上的开销会增加。
• 由于会话存储在内存中，因此存在可伸缩性问题。 如果将服务器复制到多个实例，则必须将所有用户会话复制到所有服务器。这使可伸缩性过程复杂化。 （尽管可以通过使用单个专用服务器来进行会话管理来避免这种情况，但是它并不总是可行且易于实现）

基于令牌的身份验证：

在过去的几年中，由于单页应用程序，Web API和物联网（IoT）的兴起，基于令牌的身份验证日益普及。 用于“基于令牌的身份验证”的令牌主要是Json Web令牌（JWT） 。 尽管令牌的实现方式不同，但是JWT已成为事实上的标准。

基于令牌的身份验证是无状态的 。 我们不会在服务器上或会话中存储有关用户的任何信息，甚至不会向客户端发出哪些JWT。

基于令牌的身份验证的基本流程：

1. 用户输入他们的登录凭证
2. 服务器验证凭据正确无误，然后返回签名的令牌（JWT），该令牌可以包含一些其他信息，例如user_id，权限等元数据。
3. 此令牌存储在客户端，通常存储在本地存储中-但也可以存储在会话存储或cookie中
4. 对服务器的后续请求通常将此令牌作为Bearer {JWT}形式的附加授权标头包括在内，但也可以在POST请求的正文中甚至作为查询参数发送。
5. 服务器解码JWT，如果令牌有效，则处理请求
6. 用户注销后，令牌将在客户端被销毁，无需与服务器进行任何交互

图片来源： auth0博客

如果您需要更详细的说明，请尝试此处 。

这种方法有几个好处：

• 这种方法的最大优点是它是完全无状态的，因为在服务器中不需要存储用户令牌/会话的任何记录。 每个令牌都是独立的，包含检查其有效性以及通过声明传达用户信息所需的所有数据。 这就是为什么它不会增加可伸缩性的任何复杂性。
• 使用基于cookie的方法，您只需将会话ID存储在cookie中。 另一方面，JWT允许您存储任何类型的元数据，只要它是有效的JSON。
• 使用基于cookie的身份验证时，后端必须进行查找（无论是传统的SQL数据库还是NoSQL替代方法），与解码令牌相比，往返过程可能会花费更长的时间。 另外，由于您可以在JWT内存储其他数据，例如用户的权限级别，因此可以节省其他查找调用，以获取和处理所请求的数据。
  例如，假设您有一个API资源/ api / orders可以检索通过您的应用下的最新订单，但是只有具有admin角色的用户才能查看此数据。 在基于cookie的方法中，发出请求后，您将有一个对数据库的调用，以验证会话是否有效，另一次调用以获取用户数据并验证用户具有admin角色，最后是第三个调用以获取数据。 另一方面，使用JWT方法，您可以将用户角色存储在JWT中，因此，一旦发出请求并验证了JWT，就可以对数据库进行一次调用以检索订单。
• 在可能的情况下，在移动平台上使用Cookie存在许多限制和考虑因素。 另一方面，令牌在iOS和Android上都更容易实现。 对于不具有Cookie存储概念的物联网应用程序和服务，令牌也更易于实现。

由于这些好处和简化的方法，基于令牌的身份验证在当今越来越流行。

无密码：

对“无密码身份验证”一词的第一个反应可能是- “如何在没有密码的情况下对某人进行身份验证？ 可能吗？
那是因为我们已经深深地意识到密码是我们帐户的最终保护来源。 但是，在挖掘了有关它的一些信息之后，您可能会意识到，不仅无密码身份验证可以安全使用，而且甚至比传统的用户名+密码登录更为安全。 您可能还会听到有人提高声音，试图确定密码已过时 。

什么是无密码？

正如您可能已经猜到的那样， “无密码身份验证”是一种配置登录并无需密码即可对用户进行身份验证的方法。 实施无密码认证的总体思路如下：

他们只输入电子邮件地址，而不是用户提供电子邮件/用户名和密码。 您的应用程序向他们发送该电子邮件的一次性链接，用户单击该链接即可自动登录到您的网站/应用程序。 如果使用无密码登录，则应用程序假定您提供的电子邮件确实是您的，则您将从收件箱中获取登录链接。

有一种类似的方法，它不是通过电子邮件发送一次性链接，而是通过SMS发送代码或一次性密码（OTP）。 但是您需要将您的应用程序与twilio之类的SMS服务合并 ，以使其正常工作（这也会花费您的钱）。 同样，很高兴知道代码或一次性密码也可以发送到电子邮件。

另一个不那么流行（但仅适用于Apple设备）的无密码过程是使用Touch ID ，它使用指纹进行身份验证。 这是一篇很好的文章。

如果您使用的是Slack ，那么您可能已经尝过了无密码登录。

图片来源： auth0博客

同样， Medium允许用户仅使用Email来访问其网站 。 我最近发现，如果您想在应用程序中实现无密码系统，则Auth0或Facebook的AccountKit可能是一个很好的选择。

无密码会出什么问题？

如果某人有权访问该用户的电子邮件帐户，那么他们也将有权在您的网站/应用程序中访问其帐户。 好吧，不用担心。 保护用户的电子邮件帐户绝对不是我们（作为开发人员）的责任。 同样，如果某人获得了访问其电子邮件帐户的权限，他们也可以使用“重置密码”功能来利用其“基于密码的身份验证”应用程序。 因此，让我们继续前进，因为我们对此无能为力。

有什么好处？

在回答这个问题之前，我想请您考虑一下使用“忘记密码”重设密码的频率，而不是在此之前几次失败的尝试，只是因为您忘记了该死的密码而登录站点/应用程序？ 好吧，不仅是您，我的朋友。 我们都在同一条船上。 难怪记住密码很难，特别是如果您担心帐户安全并在每个站点中设置不同的密码（请至少输入“数字”，“大写字母”，“符号”，“至少8个字符”）长度规则 ）。 使用无密码身份验证将使您免于头痛。 （我知道，现在您可能会想， “我使用您傻瓜使用的密码管理器” 。尊重您。但是请记住，您的应用程序的大众用户并不像您那样精通技术。您需要考虑这一点。）

不仅对于用户，对于开发人员也对您有好处。 现在，您无需实现“忘记密码”，“重置密码”流程。 这是所有人的双赢。 干杯!

如果您真的认为某些用户可能仍想使用该古老的电子邮件密码登录名，那么您应该像Slack一样提供两个选项，以便用户可以选择加入。

图像来源： smashingmagazine

不用说，无密码已成为当今越来越重要的登录选项，并越来越受欢迎。

单一登录（SSO）：

您是否注意到，如果您从浏览器登录到任何Google服务（例如gmail帐户），然后又转到youtube或其他任何基于Google的服务，则无需分别登录该服务？ 您会自动获得对所有Google服务的访问权限。 令人着迷，不是吗？ 虽然gmail和youtube都是Google的产品，但是它们是单独的产品，对吗？ 那么，一次登录所有产品后，他们如何验证用户身份呢？

此方法称为单点登录（SSO）。

单一登录可以通过多种方式实现。 其中之一是利用中央服务，该服务可以协调多个客户端之间的单点登录。 在Google的示例中，此中央服务是Google帐户 。 用户首次登录时，Google帐户会创建一个cookie，该cookie会在用户导航到其他Google拥有的服务时与用户保持一致。 处理流程如下：

1. 用户访问第一个Google产品。
2. 用户收到由Google帐户生成的Cookie。
3. 用户导航到另一个Google产品。
4. 再次将用户重定向到Google帐户。
5. Google帐户发现用户已经具有与身份验证相关的cookie，因此它将用户重定向到所请求的产品。

单一登录（SSO）可以非常简单地描述为“用户登录一次并获得对所有系统的访问权限，而不会提示他们在每个系统上再次登录”。 这归结为三个直接或间接相互信任的不同实体。 用户向其身份提供商（IDP）输入密码（或其他身份验证方法） ，以便获得对服务提供商（SP）的访问权限。 用户信任IdP，SP信任IDP，因此SP可以依次信任用户。

这似乎很简单，但是自定义实现会非常复杂。 有关SSO工作原理的详细说明，请参见此处 。

社交登录：

我敢打赌，您在大多数网站中经常看到以下图片，所以对它很熟悉，对吧？

这就是众所周知的“社交登录”或“社交登录” 。 使用此功能，您可以根据用户的社交网络帐户对用户进行身份验证。 用户不需要在您的应用程序中单独注册。

从技术上来说，社交登录或社交登录不是不同的身份验证方法。 相反，它是一种单点登录形式，它简化了用户向应用程序的注册/登录过程，这就是为什么您（作为开发人员）应该了解它。

社交登录是两全其美的。 为什么？
首先，对于用户而言，只需轻按一下即可登录您的应用程序，因为他们可以使用其现有的社交网络帐户，而无需记住用户名和密码（例如您的应用程序）。 这带来了丰富的用户体验。 另外，作为开发人员，您不必担心保护用户的身份验证凭据的安全，并且还可以确保（社会服务提供商）已经验证了用户的电子邮件地址。 另一个好处是，社交提供程序还将处理密码恢复过程。 好极了！

那我该怎么办呢？
作为开发人员，您需要了解更多有关基础流程的知识。 大多数社交提供程序都使用OAuth2 （有些使用OAuth1，例如twitter）进行授权以及幕后的身份验证机制。 在OAuth中要理解的主要要点是，社交提供者是“资源服务器” ，您的应用程序是“客户端” ，而尝试登录到您的应用程序的用户是“资源所有者” ，因为关键是“资源”这是用户的个人资料/身份验证信息。 因此，当用户想要使用社交提供程序登录到您的应用程序时，您的应用程序会将他们重定向到社交提供程序进行身份验证（通常会弹出一个带有社交提供程序URL的窗口）。 除了成功的身份验证之外，用户还需要批准您的应用程序的许可，才能从社交提供程序访问用户的个人资料信息。 然后，社交提供程序将使用一些访问令牌将用户重定向回您的应用程序。 下次使用该访问令牌时，您的应用程序可以向社交服务提供商询问用户的个人资料信息。 简而言之，这就是OAuth的工作方式（跳过一些技术细节以便于说明）

要在您的应用程序中实现社交登录，您可能需要在社交提供程序站点中注册您的应用程序，这将为您提供一些app_id和其他相关密钥以进行配置以进行通信。 您将在相应的社交服务提供商的网站上获得这些信息。 另外，还有一些流行的库/程序包（例如Passport ， Laravel Socialite等），它们可能会简化您的过程，使您从负担中解脱出来，以了解详细的细节。

两因素验证（2FA）：

两要素身份验证（2FA）通过要求两种方法（也称为factor ）来验证用户身份来增强访问安全性。 它是一种多因素身份验证 ，可提供额外的安全性。 您可能以前没有意识到，但是当您去ATM机房或自动取款机取钱时，您正在通过两因素身份验证系统进行身份验证。 您必须具有要进行身份验证的银行卡（ 您拥有的东西 ）和PIN（ 您知道的东西 ）的正确组合。 如果有人偷了您的ATM卡，那么在他们也知道您的PIN之前，它的用处不大。 这意味着在两因素身份验证系统中，仅在成功向身份验证机制提供几条单独的证据后，才授予用户访问权限。
您可能熟悉的另一个示例是Google ， facebook等的两步验证。在您的帐户中启用两因素验证后，每次需要登录帐户时，首先需要提供登录凭据，例如电子邮件，密码（验证您是否知道凭据），然后通过SMS发送一次密码（OTP）（验证您是否拥有该设备），并且您必须正确输入该密码才能完成登录过程。 如果您的密码已被泄露，您的帐户仍然是安全的，因为攻击者如果没有验证码就无法完成第二步。

图片来源： https : //dzone.com/articles/implementing-two-factor-authentication-using-authe

除了OTP之外，另一种常见方法是将用户的生物特征数据（例如指纹或视网膜）用作第二因素。

两因素身份验证基于用户提供以下三个“事物”中的两个 ：

• 您所知道的 -帐户的密码或密码
• 您拥有的东西 —可以生成一次性密码的物理设备，例如手机或软件应用程序
• 您就是某物 -生物学上的独特功能，例如指纹，声音或视网膜

学习密码或密码是大多数黑客的追求。 访问物理令牌生成器或获取生物学特征更加困难，这也是2FA有效地为用户帐户提供更高安全性的原因。

那么，2FA是一种万能的解决方案吗？ 也许 不是 。

但是，它仍然可以帮助您增强应用程序中的身份验证安全性。 您将如何在系统中实施2FA解决方案？ 好吧，最好使用一些现有的解决方案，例如Auth0或Duo，而不是自己动手做。

奖励主题：身份验证与授权：

我们中有些人可能会错误地互换使用“认证”和“授权”这两个术语。 但是，这两个词并不意味着同一件事。

• 身份验证是验证您身份的过程。 使用用户名和密码登录到应用程序时，您正在进行身份验证。
• 授权是验证您有权访问某些内容的过程。 这意味着允许您执行一组权限。 例如，如果您在应用程序中创建了资源，则您可能是唯一被允许删除该资源的人（作为所有者），其他用户没有被“授权”删除该资源。

你还在吗？

恭喜，您已经成功阅读了冗长而乏味的文章。 😃

希望您得到有关这些主题的简要概述。 如果您发现任何错误或认为本文需要任何改进，请发表评论。

From: https://hackernoon.com/how-do-you-authenticate-mate-f2b70904cc3a