从0开始构建一个Oauth2Server服务 12 login

从0开始构建一个Oauth2Server服务 12

用户登录

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

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

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

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

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

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

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

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

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