service - 程序员在开发自己的 oAuth 服务时应该考虑哪些技术细节？

Question

程序员在开发自己的 oAuth 服务时应该考虑哪些技术细节？

一直试图找出指南，但发现大部分oAuth相关文章从消费者的角度进行讨论(即如何消费他人的服务)。我想设计自己的oAuth系统与我的授权服务和资源服务。我应该遵循哪些技术细节？

Answer 1

您可能已经阅读了 RFC，但以防万一，您可以从它们开始:

oAuth 2.0“核心”(RFC 6749 和 6750)

代码交换证明 key (PKCE) (RFC 7636)

oAuth 实现者(客户端或其他)的最佳“打包”指南可通过 IETF 最佳当前实践 (BCP) 获得。大多数人都知道 IETF RFC，并且(令人困惑地)BCP 作为带有 RFC 编号的 RFC 发布。尽管如此，它们是最佳实践和 not formal specifications :

The BCP process is similar to that for proposed standards. The BCP is submitted to the IESG for review, and the existing review process applies, including a "last call" on the IETF announcement mailing list. However, once the IESG has approved the document, the process ends and the document is published. The resulting document is viewed as having the technical approval of the IETF, but it is not, and cannot become an official Internet Standard.

您要审核的 BCP:

oAuth security (截至撰写本文时最新)

oAuth browser-based apps (截至撰写本文时最新)。

oAuth native apps (于 2017 年作为“核心”oAuth 2.0 RFC 的更新发布，仍然值得一读)

JSON Web Tokens for oAuth (最新)

这些文档以威胁模型术语为框架——它们涵盖了攻击(或“安全考虑”作为一种稀释格式)和对策。您可能正在寻找一种更直接的构建块类型的路线图，也许应该有一个作为教育工具。必须使用威胁模型的初步证据来开发真实世界的 oAuth 实现。

作为一名武士 said : ...未经考验的剑术，就像在陆地上掌握的游泳艺术。