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

Question

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

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

Answer 1

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

1. oAuth 2.0“核心”（RFC 6749和6750）
2. 代码交换证明密钥 (PKCE) (RFC 7636 )

oAuth 实施者（客户端或其他）的最佳“打包”指南可通过 IETF 最佳当前实践 (BCP) 获得。大多数人都知道 IETF RFC，并且（令人困惑地）BCP 作为带有 RFC 编号的 RFC 发布。尽管如此，它们是最佳实践，而不是正式规范：

BCP 过程类似于提议标准的过程。BCP 提交给 IESG 进行审查，现有的审查过程适用，包括 IETF 公告邮件列表中的“最后通知”。但是，一旦 IESG 批准了该文件，该过程就会结束并发布该文件。由此产生的文件被视为获得了 IETF 的技术批准，但它不是，也不能成为正式的互联网标准。

您要审核的 BCP：

1. oAuth安全性（截至撰写本文时是最新的）
2. oAuth 用于基于浏览器的应用程序（在撰写本文时是最新的）。
3. 适用于本机应用程序的oAuth （于 2017 年发布，作为“核心”oAuth 2.0 RFC 的更新，仍然值得一读）
4. oAuth 的 JSON 网络令牌（最新）

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

正如一位武士所说：......未经战斗考验的剑术就像在陆地上掌握的游泳艺术。