Oauthlib: 设备代码授权类型

该规范仍处于草案https://tools.ietf.org/html/draft-ietf-oauth-device-flow-13中，但如果有人开始在 oauthlib 中实现它，那就太好了。 欢迎 PR

@JonathanHuot是否有关于贡献者可以从哪里开始添加此功能的良好文档？

您可以在我们的 Gitter 频道上提问。

正如 thedrow 所说，我们在 Gitter 中非常被动。 您还可以查看其他赠款，并了解它们目前​​是如何实施的。 另请注意，我们将 _client_ 代码与 _server_ 代码区别开来，但有时我们对客户端和服务器都有共同的代码。
如果您正在研究客户端部分，理想情况下，您还应该向requests-oauthlib提出 PR，这是 oauthlib 下游的主要“客户端”。

您还可以查看我们的贡献页面https://oauthlib.readthedocs.io/en/latest/contributing.html了解更多通用内容。

我对服务器端更感兴趣，因为我需要为我正在从事的项目实现这一点。 Atm 我已经使用我的自定义代码完成了它，但我非常想以正确的方式完成它。

将跳上 gitter 讨论:)

我不禁觉得将客户端排除在外是个坏主意。

我可以构建客户端，但设备代码服务器本身仍然需要大量工作

我只是在非常需要 JWT 支持的背景下考虑为此所需的架构。

@duaneking我们是否有关于该更改的未解决问题，也许我们可以讨论一下？ 我可以暂停这项工作，直到发生这种变化。

@duaneking ，完全的 JWT 支持可能会改变架构，但不应该阻止@jcampbell05完成他的工作。 Device Flow 与 JWT 无关，不应与 JWT 新架构发生冲突。
_EDIT:_ 如果 JWT 新架构意味着大量重构，我更愿意完成这个 DeviceFlow 并在 DeviceFlow 完成后进行 JWT 重构。 只是因为没有人开始这个重构讨论，它比DeviceFlow还远未完成。

关于客户端，如果它在第一次 PR 期间实施，那我承认会很棒。 此外，它有助于测试设备流实现本身。

@JonathanHuot所以我一直在考虑客户端我基本上是在编写自己的客户端来测试它，所以我想在这个库中实现也不会受到伤害。

我最大的反对是让功能只完成了一半。 如果您要添加客户端，则可以解决此问题。 谢谢。

我现在没有足够的带宽来完成这个 - 所以希望有人可以接受这个，或者我可以稍后继续

草案中没有更多https://tools.ietf.org/html/rfc8628