我正在编写oauth2提供程序，但不确定如何实现客户端注册。 oauth2 specification不涵盖这方面：
客户端向授权服务器注册的方式超出了本规范的范围，但通常涉及最终用户与HTML注册表单的交互。
此外，oauthlib documentation对Client数据模型有以下说法：
通常的做法是将每个客户与一个现有用户相关联。无论您是否关联客户端和用户，请确保您能够保护自己免受恶意客户端的侵害。
现在我确实希望保护自己免受恶意客户端的侵害，但如果注册用户需要注册客户端，我如何将客户端链接到用户？
oauth2 spec再次对此有所说明，但它非常神秘：
客户端注册不需要客户端和授权服务器之间的直接交互。当授权服务器支持时，注册可以依赖于其他方式来建立信任并获得所需的客户端属性（例如，重定向URI，客户端类型）。例如，可以使用自发布或第三方发布的断言，或使用可信通道执行客户端发现的授权服务器来完成注册。
问题
答案 0 :(得分：8)
在回答这个问题时，我将假设已经有一个访问控制框架，该提供程序将附加到该框架，并且将使用此提供程序的应用程序将具有HTTP访问权限并且具有处理HTML表单的功能，因为没有这个问题提供的详细信息（即这个提供者将采用什么样的框架，或者是某些自制框架上完全裸露和独立的东西）。
我正在撰写oauth2提供商，但我不确定如何实施客户注册。 oauth2规范并未涵盖这方面：
客户端向授权服务器注册的方式超出了本规范的范围，但通常涉及最终用户与HTML注册表单的交互。
虽然它没有明确说明，但它确实表明客户端的典型注册涉及最终用户与表单的交互。如果您看到其他人如何做到这一点（例如通过imgur's API, OAuth 2 user documentation），您会发现它提供了一个注册链接，并且嘿了客户注册的方式。不需要OAuth 2，因为您已通过浏览器进行了身份验证。
现在我肯定会喜欢保护自己免受恶意客户的侵害，但我怎样才能将客户端链接到用户
通过将您的服务器应用程序的客户端详细信息表示链接到创建这些客户端详细信息的用户（由某个系统跟踪）？它不像用户特定数据突然变得更神秘，因为它用于验证OAuth2客户端。如果您使用这些客户端详细信息（来自您的日志）发现与访问相关的滥用行为，您可以撤消与该客户端相关的凭据，并惩罚拥有该客户端的用户。 （除非它是他们的客户......呃，你使用该客户端的其他用户正在进行滥用，但你应该能够看到它，对吗？）
如果注册用户需要注册客户？
如果你真的希望让人们在注册客户之前使用他们的客户注册他们的客户，那就非常疯狂（即鸡和鸡蛋问题不应该是需要存在）。在规范中没有任何地方有人提出它们是相互包容的问题。在这里，为了简化这一点：
这两件事完全是彼此分开的。你必须拥有一个在另一个之前（实际上，你可以创建一个同时生成客户端凭据的用户注册表单，但我离题了），但实际上，注册客户端基本上是可以减少的对于在该客户端与其注册的提供者之间共享的某些凭据。
您也可以制作您自己的注册客户，因为您可以完全控制提供商，您可以注入您的注册客户将使用的任何凭据，以满足您的需求，包括注册新用户，但......
如果注册用户需要注册客户端，如果需要链接到用户，应该如何注册客户端？
您知道可以使用标准HTML注册表单注册用户吗？只需使用框架提供的用户注册表单，或者如果该框架尚未提供一个*，则编写一个*。
如果不需要链接到用户，应如何注册客户？
当我为Plone实施OAuth1提供程序时，客户端注册只能由网站的管理员/管理员完成，因此用户无法做到，因此有人必须联系网站所有者以了解如何执行此操作。这通常消除了与不将客户端链接到用户相关的安全问题（因为客户现在链接到通过外部方式编码那些不一定是网站用户的实际人员）。
我意识到我并没有真正回答这个问题，但这取决于您的实施以及您决定限制/提供的需求/限制。我的意思是你可以在你的网站上拥有一个完全匿名的表格并让它撕裂，但我不认为你想要这样，因为这会大大削弱应用程序的安全性。
重定向URI，客户端类型和第三方发布的断言是什么意思？
如果你转到RFC中指定的部分，你会在那里找到答案：
实际上有很多方法可以破坏用户的安全性。 （资源所有者的）数据，如果没有仔细理解，但授权服务器使用该数据将资源所有者的用户代理重定向回客户端＆＃34;，作为授权在授权服务器上完成，授权服务器是提供商的基础设施的一部分。因此，通常，在资源所有者通过此重定向URI授权客户端访问之后，客户端必须让授权服务器知道它返回自身的位置/方式。但是，如果未验证指定的重定向URI，则可能会发生安全问题。
例如，本机应用程序（客户端类型为public的客户端配置文件）（以前，我来自OAuth1背景）将在应用程序中嵌入完整的客户端凭据，这些凭据将由恶意攻击者提取。竞标伪装成合法的Web应用程序（另一个客户端配置文件，但可以被视为机密客户端类型），它利用您的应用程序的服务。一旦敌对攻击者启动并运行，他们将诱使您的用户（资源所有者）使用他们的伪装网站，并通过您的授权服务器授予伪装网站他们的访问权限，如果重定向URI未经验证，它将重定向您的用户（资源）所有者）使用授权码（如section 1.3中所述）向攻击者授予攻击者访问资源所有者数据的权限。
这是一个简单的常见情况 - 另一个问题是您的其他Web应用程序客户端可能在没有他们知道的情况下有凭据泄漏，从而导致这种情况。
因此，这就是为什么他们建议您只应将用户代理重定向到客户端注册过程中先前与授权服务器建立的客户端重定向端点...完成与之交互之后资源所有者＆＃34;，这可能意味着只有注册到该客户端的域名才是合法的重定向目标，否则出现问题，您的授权服务器将中止并且不提供授权授权。
再次，仔细阅读/仔细检查所有内容。
第三方发布的断言
与自行发布的客户端注册相反，您的应用程序可能会将客户端身份验证委派给将为您进行验证的第三方。如果您不得不担心这一点，并且不知道从哪里开始，我建议您忽略这一点，只做自己发布的客户。
*您是否确实确定要编写OAuth2提供程序而没有任何底层用户/ ACL框架供您将其挂钩？我的意思是你可以写一个但你应该真的在你担心OAuth2之前先构建那个部分（再次，我没有做出任何断言，因为这个问题没有提供相关信息）。
现在，如果您不是将这个作为现有框架的一部分，而只是想要玩具/尝试学习的独立内容，我强烈建议您选择其他内容，因为这可能超出了您的能力范围。一个正确的方式。特别是如果您还没有完全理解这对于底层ACL以及资源所有者数据的安全性以及其他相关内容的影响。
没有冒犯，但这些事情很难正确完成。即使是规模较大的公司也有had security issues及其OAuth2解决方案。
最后，根据经验，我花了大约四（4）周（！）在几年前盯着OAuth1规范，使用写得不好的Python OAuth库（后来替换为oauthlib，这是在我获得与提交的提供程序直接相关的单行代码之前，尝试在Plone之上构建OAuth1提供程序更多更好。编写的大量垃圾/试用代码被丢弃了，这样做是因为理解所有这些东西实际上需要时间（被授予，我不是完全在这个时间工作，还有其他责任，这让我分心）。另一部分时间用于尝试了解如何在Zope / Plone层将用户/安全性内容放在一起。虽然我对该框架的那一方仍然相对较新，但我可以向你保证，这条道路并不容易......但我似乎确实发现OAuth 2在某些方面清理了一些东西，以便更容易理解，但发现security may have been weakened。也就是说，我目前没有立即计划将我的Plone插件移植到支持2.0，因为我的赞助商不需要这样做，所以我建议的那些可能与2.0略有不同。如果其他人已经阅读过这篇文章，我很乐意听取您的意见。我写的文字比我原先打算的更多，哎呀。
无论如何，祝你的冒险好运。
答案 1 :(得分：0)
另外，对于动态注册，请同时阅读此规范 https://tools.ietf.org/html/rfc7592