从0开始构建一个Oauth2Server服务 <12> 用户登录及授权

用户登录

单击应用程序的“登录”或“连接”按钮后，用户首先会看到的是您的授权服务器 UI。由授权服务器决定是要求用户在每次访问授权屏幕时都登录，还是让用户在一段时间内保持登录状态。如果授权服务器在请求之间记住了用户，那么它可能仍需要请求用户的许可才能在以后的访问中授权应用程序。

通常像 Twitter 或 Facebook 这样的网站希望他们的用户在大部分时间都登录，因此他们为他们的授权屏幕提供了一种方式，通过不要求他们每次都登录来为用户提供简化的体验。但是，根据您的服务以及第三方应用程序的安全要求，可能需要要求或允许开发人员选择要求用户在每次访问授权屏幕时都登录。

在谷歌的API中，应用程序可以添加prompt=login授权请求，这会导致授权服务器强制用户重新登录，然后才会显示授权提示。

在任何情况下，如果用户已注销，或者在您的服务上还没有帐户，您需要提供一种方法让他们在此屏幕上登录或创建帐户。

从0开始构建一个Oauth2Server服务 <12> 用户登录及授权_应用程序

可以按照您希望的任何方式对用户进行身份验证，因为这在 OAuth 2.0 规范中没有指定。大多数服务使用传统的用户名/密码登录来验证其用户，但这绝不是解决问题的唯一方法。在企业环境中，一种常见的技术是使用 SAML 来利用组织中现有的身份验证机制，同时避免创建另一个用户名/密码数据库。

这也是授权服务器必须要求用户进行多因素身份验证的机会。在使用用户的主要用户名和密码进行身份验证后，授权服务器可能需要第二个因素，例如 WebAuthn 或 USB 安全密钥。这种模式的好处是应用程序不需要知道是否正在使用或需要多因素身份验证，因为这完全发生在用户和授权服务器之间，应用程序看不到。

一旦用户通过授权服务器进行身份验证，它就可以继续处理授权请求并将用户重定向回应用程序。有时服务器会认为登录成功也意味着用户授权了应用程序。在这种情况下，带有登录提示的授权屏幕需要包含描述用户通过登录批准此授权请求这一事实的文本。这将导致以下用户流程。

从0开始构建一个Oauth2Server服务 <12> 用户登录及授权_应用程序_02

如果授权服务器需要通过 SAML 或其他内部系统对用户进行身份验证，则用户流程如下所示

从0开始构建一个Oauth2Server服务 <12> 用户登录及授权_应用程序_03

在此流程中，用户在登录后被定向回授权服务器，在那里他们会看到授权请求，就像他们已经登录一样。

授权接口 The Authorization Interface

从0开始构建一个Oauth2Server服务 <12> 用户登录及授权_应用程序_04

授权界面是用户在收到来自第三方应用程序的授权请求时将看到的屏幕。这通常也称为“同意屏幕”或“许可提示”。由于要求用户授予对第三方应用程序的某种级别的访问权限，因此您需要确保用户拥有他们需要的所有信息，以便就授权应用程序做出明智的决定。

这通常仅在用户登录第三方应用程序而不是第一方应用程序时才需要。例如，当登录 Gmail 时，您不会期望 Google 询问您 Gmail 是否可以知道您的帐户信息，因为应用程序 (Gmail) 和 OAuth 服务器都是同一公司产品的一部分。但是，如果您登录到将从您的 Gmail 帐户发送电子邮件的第三方邮件列表应用程序，那么作为用户的您了解该第三方应用程序将被授予访问权限的内容以及它将是什么变得至关重要可以使用您的帐户。

授权接口通常具有以下组件：

网站名称和徽标

该服务应该很容易被用户识别，因为他们需要知道他们授予访问权限的服务。但是你在你的主页上标识你的网站应该与授权界面一致。通常，这是通过在屏幕的一致位置显示应用程序名称和徽标，和/或通过在整个网站上使用一致的配色方案来实现的。

用户识别

如果用户已经登录，您应该向用户表明这一点。这可能类似于在屏幕的上角显示他们的姓名和照片，就像您在网站的其余部分一样。

重要的是，用户知道他们当前登录的是哪个帐户，以防他们管理多个帐户，这样他们就不会错误地授权不同的用户帐户。

申请详情

授权界面应该清楚地标识发出请求的应用程序。除了开发人员提供的应用程序名称之外，显示网站和应用程序的徽标通常也是一个好主意。这是您在开发人员注册应用程序时收集的信息。我们在Client Registration中详细讨论了这一点。

请求的范围

授权请求中提供的范围值应该清楚地显示给用户。范围值通常是表示特定访问权限的短字符串，因此应该向用户显示更易于阅读的版本。

例如，如果一个服务定义了一个“私有”的范围来表示对私有配置文件数据的读取访问，那么授权服务器应该说一些类似“这个应用程序将能够查看您的私有配置文件数据”的内容。如果范围明确允许写入访问，则还应在描述中加以标识，例如“此应用程序将能够编辑您的个人资料数据”。

如果不存在任何范围，但您的服务仍授予对用户帐户的一些基本级别的访问权限，则您应该包含一条消息来描述应用程序将获得的访问权限。如果省略范围意味着应用程序唯一获得的是用户标识，您可以包含一条消息，表示“此应用程序需要您登录”或“此应用程序需要了解您的基本个人资料信息”。

有关如何在服务中有效使用范围的更多信息，请参阅范围。

请求的或有效的生命周期

授权服务器必须决定授权的有效期、访问令牌的持续时间以及刷新令牌的持续时间。

大多数服务不会自动使授权过期，而是希望用户定期查看和撤销对他们不想再使用的应用程序的访问权限。但是有些服务默认提供有限的令牌生命周期，要么允许应用程序请求更长的生命周期，要么强制用户在授权过期后重新授权应用程序。

无论您对授权的生命周期做出怎样的决定，您都应该向用户明确说明该应用程序能够代表用户执行多长时间。这可以是简单的一句话，比如“此应用程序将能够访问您的帐户，直到您撤销访问权限”或“此应用程序将能够访问您的帐户一周”。有关令牌生命周期的更多信息，请参阅访问令牌生命周期。

允许否认

最后，授权服务器应向用户提供两个按钮，以允许或拒绝请求。如果用户未登录，您应该提供登录提示而不是“允许”按钮。

如果用户批准请求，授权服务器将创建一个临时授权码并将用户重定向回应用程序。如果用户单击“拒绝”，服务器将重定向回应用程序，并在 URL 中包含错误代码。下一节将详细介绍应如何处理此响应。