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

Question

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

我一直在尝试找到一些指南，但是发现大多数与oAuth相关的文章都是从消费者的角度进行讨论（例如如何使用其他人的服务）。我想设计自己的oAuth系统，包括我的授权服务和资源服务。我应该遵循哪些技术细节？

- Sazzad Hissain Khan

---

开发自己的oAuth服务可能非常复杂，这取决于您想要实现什么以及您想要支持哪些身份验证流程，例如隐式授权、授权代码等。如果您使用像Azure AD、Cognito、Okta、Auth0.com等著名的身份验证提供程序，则需要了解更多内容。它们不仅提供服务器实现，而且还提供客户端SDK来自动刷新令牌等功能。如果您打算进行全面实现，则需要至少了解身份验证流程、auth2.0、OpenID Connect协议、令牌、安全性以及可能我没有意识到的其他方面。 - Imran Arshad

你有没有考虑不去构建它呢？开个玩笑，oAuth服务很少是公司价值主张的一部分，更少是区分因素，这意味着大多数公司最好使用或购买现成的解决方案。当然，并不是说没有有效的情况需要这样做，但必须清楚地解释。 - Savvas Kleanthous

@AKleanthus，我已经更新了标题。我认为之前有误导性。 - Sazzad Hissain Khan

Answer 1

您可能已经阅读过RFC，但以防万一，这就是您想要开始的地方：

1. oAuth 2.0 "核心"（RFC6749和6750）
2. 代码交换的证明密钥（PKCE）（RFC 7636）

对于oAuth实施者（客户端或其他），最好的“打包”指南可以通过IETF最佳当前实践（BCP）获得。大多数人知道IETF RFCs，而BCPs作为带有RFC号的RFC发布，尽管如此，它们是最佳实践而不是正式规范：

BCP流程与拟议标准的流程相似。将BCP提交给IESG进行审查，包括在IETF公告邮件列表上进行“最后呼叫”的现有审查流程。但是，一旦IESG批准了文档，流程就结束了，文档就会被发布。生成的文档被视为获得了IETF的技术批准，但它不是，并且不能成为官方的Internet标准。

您要审核的BCP：

1. oAuth 安全（截至本文撰写时最新）
2. 面向基于浏览器的应用程序的oAuth（截至本文撰写时最新）。
3. 面向本地应用程序的oAuth（作为“核心”oAuth 2.0 RFC的2017年更新，仍然是一个不错的阅读材料）
4. oAuth的JSON Web Tokens（最新）

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

作为一名武士所说：...在战斗中未经检验的剑术就像是在陆地上掌握的游泳艺术。

- identigral

Answer 2

我也很想知道您为什么想要开发自己的身份验证解决方案。

但是，暂且不谈这个问题，有一个开源项目可以完全满足您的需求 - Identity Server。您可以查看他们的源代码或者fork它，在其基础上构建自己的应用程序。

此外，请参考“identigral”在各种文档中的答案。

- eddyP23