从0开始构建一个Oauth2 Server服务 27 #
授权服务器要求 #
支持设备流对于授权服务器来说并不是大量的额外工作。在向现有授权服务器添加对设备流的支持时，请记住以下几点。
设备代码请求 #
设备将向授权服务器发出请求，以获取该流程所需的一组验证码。以下参数是请求的一部分。
client_id– 必填，如客户端注册中所述的客户端标识符。scope– 可选
验证客户端 ID 和范围后，授权服务器返回包含验证 URL、设备代码和用户代码的响应。除了上面给出的示例之外，授权服务器还可以返回一些可选参数。
device_code– 必填，授权服务器生成的验证码。user_code– 必需，用户将在设备屏幕上输入的代码应该相对较短。通常使用 6-8 个数字和字母。verification_uri– 必需，用户应访问以开始授权的授权服务器上的 URL。用户需要在他们的计算机或手机上手动输入此 URL。expires_in– 可选，设备代码和用户代码的生命周期（以秒为单位）。interval– 可选，客户端在对令牌端点的轮询请求之间应等待的最短时间（以秒为单位）。
用户code #
在许多情况下，用户最近的设备将是他们的移动电话。通常这些界面比完整的计算机键盘更受限制，例如 iPhone 如何需要额外的点击来更改键壳或切换到数字输入。为帮助减少数据输入错误并加快代码输入速度，用户代码的字符集应考虑这些限制，例如仅使用大写字母。
用于设备代码的合理字符集是不区分大小写的 AZ 字符，没有元音字母以避免意外拼写单词。这导致 base-20 字符集BCDFGHJKLMNPQRSTVWXZ。比较输入的代码时，最好忽略不在字符集中的任何字符，例如标点符号。遵循此准则且熵为 20^8 的示例代码是BDWP-HQPK. 授权服务器应该不区分大小写地比较输入的字符串，忽略标点符号，因此应该允许以下内容作为匹配项：bdwphqpk.
验证网址 #
设备将显示的验证 URL 应尽可能短，并且易于记忆。它将显示在可能非常小的屏幕上，用户将不得不在他们的计算机或手机上手动输入。
请注意，服务器应返回包含 URL 方案的完整 URL，尽管某些设备可能会在显示 URL 时选择对其进行修剪。因此，服务器应配置为将 http 重定向到 https，并在普通域和带有 www 前缀的域上提供服务，以防用户输入错误或设备省略 URL 的该部分。
Google 的授权服务器是易于输入的短 URL 的一个很好的例子。代码请求的响应是，https://www.google.com/device但所有设备需要显示的是google.com/device，谷歌将适当地重定向。
非文本界面的优化 #
没有显示或非文本显示的客户端显然无法向用户显示 URL。因此，有一些额外的方法可用于将验证 URL 和用户代码传达给用户。
该设备可能能够通过 NFC 或蓝牙，甚至通过显示二维码来广播验证 URL。在这些情况下，设备可以使用参数将用户代码作为验证 URL 的一部分user_code。例如：
https://authorization-server.com/device?user_code=BDWP-HQPK
这样，当用户启动 URL 时，可以在验证界面中预先填写用户代码。建议授权服务器仍然要求用户确认密码而不是自动进行。
如果设备具有显示代码的能力，即使它不能显示 URL，也会通过提示用户确认验证界面上的代码与其设备上显示的代码相匹配来获得额外的安全性。如果这不是一个选项，那么授权服务器至少可以要求用户确认他们刚刚请求授权设备。
二维码 #
现在都会在这些设备上使用二维码展示, 使用手机相机或者二维码的APP扫码就可以完成登录认证.