Question

考虑此Azure AD OAuth 2.0设备流授权请求：

POST https://login.microsoftonline.com/common/oauth2/devicecode
Content-Type: application/x-www-form-urlencoded

client_id=12345678-1234-1234-1234-123456789012
&grant_type=device_code
&resource=https://graph.microsoft.com

（跳过urlencoding以提高可读性）

根据this draft，响应应包含verification_uri参数：

verification_uri

必需的。授权服务器上的最终用户验证URI。 URI应该简短且易于记忆，因为将要求最终用户手动将其键入其用户代理。
{
   "device_code": "GMMhmHCXhWEzkobqIHGG_EnNYYsAkukHspeYUk9E8",
   "user_code": "WDJB-MJHT",
   "verification_uri": "https://www.example.com/device",
   ...

但Azure AD的响应包含而是verification_url（注意url而不是uri）：

"verification_url": "https://aka.ms/devicelogin"

这只是Azure AD设备流程实施中的一个错误吗？我应该将两种变体都视为有效吗？这是否会在下一个草稿中重命名为verification_url？

另外一个问题，我可以从Azure AD v2 端点请求设备流授权吗？

令牌端点似乎以/common/oauth2/v2.0/token的形式存在，但其代码请求对象返回404，/common/oauth2/v2.0/devicecode。

有/common/oauth2/devicecode，但我稍后无法使用/common/oauth2/v2.0/devicecode（立即返回 AADSTS70019验证码已过期。）。

Answer 1

这可能不是一个错字。 IETF草案（您提到的）得到了谷歌和微软的支持。但两家公司都在不考虑这种差异的情况下实施了它，即“verification_uri”与“verification_url”。

谷歌排在第一位。他们在几年前实施了设备流程。我不确定首次发布的确切日期，但它已于2012年推出。他们从一开始就使用了“verification_url”！ IETF草案的第一个版本可以追溯到2015年，由于某种原因，负责草案的谷歌团队决定使用“verification_uri”，尽管他们自己的实施已经使用了“verification_url”多年。他们既没有改变草案，也没有改变他们的实施。他们也在文档中使用“verification_url”。

另一方面，Facebook使用草案版本作为字段名称，即“verification_uri”。查看他们的文档（并且实现与文档一致）：https://developers.facebook.com/docs/facebook-login/for-devices

我还没有找到微软（即Azure）设备流程实现的官方文档，但这里有关于这个主题并位于* .microsoft.com域的几篇帖子/文章：

后者伴随着GitHub回购：https://github.com/Azure-Samples/active-directory-dotnet-deviceprofile

以下是一些非MS来源：

实际上后者（它是日语）是我能找到的Azure设备流程实现的第一个详细示例。 :-)它也有“verification_url”。

至于您的“其他问题”（“我可以从Azure AD v2端点请求设备流授权吗？”），我不知道。微软的设备流程实现甚至不是官方的（至少支持，至少缺少文档表明这一点），所以它可能会发生变化。

v2.0协议页面也没有提到“devicecode”端点。参见：

所以现在我建议不要在Azure的设备流程上构建类似生产的东西。

Azure AD设备流验证_url

1 个答案: