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