应用系统的设计与实现

今天的应用程序使用了大量的登录和身份验证方法和工作流程。在这里，我将分享最相关和最有效的身份验证工作流程，您可以使用这些工作流程作为基础，为传统 web 应用程序、单页应用程序和本地移动应用程序设计和设计身份验证系统。

传统 Web 应用程序的认证工作流

传统的 web 应用程序加载一个 web 页面，并使用基于消息的模型提供用户功能，其中浏览器基于地址栏中的 URL 向 web 服务器发出 HTTP 请求。服务器用 HTML、 CSS 和 JavaScript 响应这个请求，然后在浏览器中显示一个资源。与传统的 络应用程序一样，新的 络应用程序通常仍然以这种方式提供功能。

当用户提交表单或单击链接或按钮时，浏览器会向 web 服务器发送一个新的消息 HTTP 请求，并更改地址栏中的 URL。服务器再次响应，返回 HTML、 CSS 和 JavaScript，然后在浏览器中显示一个资源。

浏览器对于传统的 web 应用只支持两种 HTTP 方法: GET 和 POST。GET 用于从指定的资源请求数据，POST 用于向服务器发送数据以创建或更新资源。

下面是一些你可以用来进行传统 web 应用登录和验证的工作流程。请注意，应用程序后端是应用程序的后端(而不是身份提供者或 IdP) ，本机登录表单是直接构建到应用程序中的表单，而不是外部登录表单。

单页应用程序的身份验证工作流

一个单页面的 web 应用(SPA，读作“ SPA”或“ S-P-A”)在从 页加载 HTML、 CSS 和 JavaScript 源代码后，完全在浏览器中运行。在检索组成应用程序的 HTML、 CSS 和 JavaScript 之后，浏览器调用一个 JavaScript 框架，引导然后呈现应用程序。

Spa 调用 api 来处理用户交互和输入。例如，如果用户单击链接或提交表单，SPA 可能呈现不同的页面或表单。

Api 是使用 XMLHttpRequest 调用的，XMLHttpRequest 是一个内置的浏览器对象，可以在 JavaScript 中发出 HTTP 请求。当服务器响应时，浏览器中运行的 JavaScript 动态更新数据，而不是执行完整页面刷新。

Spa 使用单一的请求和响应模型。因为浏览器使用 XMLHttpRequest，所以它可以支持 GET 和 POST，以及其他标准的 HTTP 方法，如 PUT 和 DELETE。(PUT 用于替换指定资源的所有当前表示形式，DELETE 用于删除指定资源。)选择的 HTTP 方法告诉服务器如何处理请求。

以下是一些可用于 SPA 登录和身份验证的工作流程。

当对 SPAs 使用 OAuth 时，请注意浏览器从 SPA 导航到 OAuth 提供者。一旦 OAuth 工作流完成，浏览器就会被发送回 SPA 页面，在那里它可以使用缓存的资产快速重新启动 SPA。

本地移动应用程序的认证工作流

本地移动应用程序通常安装在移动设备或任何智能设备上，通过在线市场如 App Store 和 Google Play Store。单击设备上的应用程序图标启动设备操作系统，该操作系统启动应用程序及其用户界面。

几乎所有本地应用程序都在服务器上调用 api 来处理用户交互和输入，比如单击按钮和提交表单。本地应用程序经常使用设计来直接访问源代码的所有类、对象、函数和方法的库，以便与 API 进行快速通信并简化 API 调用。

以下是一些你可以用于本地移动应用登录和认证的工作流程:

使用 JWTs 和刷新令牌向应用程序后端本机登录表单

使用 JWTs 刷新令牌(推荐)将本地登录表单发送到 FusionAuth

OAuth 2资源所有者密码凭据授权使用 JWTs 和刷新令牌

请注意，本地移动应用程序还可以使用 OAuth 授权代码授权将授权代码交换为访问令牌。这个工作流程适用于许多国内流离失所者，基本上与前面的传统 络应用程序和单页应用部分所描述的相同。主要区别在于，本地应用程序在 OAuth 工作流结束时从 web 视图中提取 JWT 并刷新标记。

认证系统最佳选择

上面列出的工作流程应该为您提供一个基线，以便遵循身份验证系统的最佳实践，并为您的应用程序设计一个合理的登录和身份验证系统。虽然这些示例使用 FusionAuth 作为 IdP，但是可以使用任何 IdP。大多数国内流离失所者能够进行各种各样的登录和认证工作流程，这里的例子并非详尽无遗。

当你为传统 络应用程序、单页应用程序或本地移动应用程序设计身份验证系统时，请记住一些 IdP 登录工作流可能会带来严重的安全风险。正如所有与数字身份、用户和数据安全有关的事情一样，明智地选择 IdP 和身份验证工作流程非常重要。