从0开始构建一个Oauth2Server服务 13 Authorization Interface

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

授权接口 The Authorization Interface

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

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

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

网站名称和徽标

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

用户识别

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

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

申请详情

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

请求的范围

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

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

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

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

请求的或有效的生命周期

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

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

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

允许否认

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

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