两家公司。
这些公司彼此之间有着可信赖的关系。
CorporateCompany 希望他们的员工可以在 MegaSocialPlatform 上重复使用他们当前的CorporateCompany.com登录凭据，以便他们的员工不必再创建另一个帐户。
CorporateCompany 的开发能力有限，并且没有实施任何完全成熟的OAuth服务。
如果他们制作一个只能发布电子邮件/密码组合的API，如果它是正确的，它会返回一些带有CorporatyCompany唯一ID，电子邮件和名称的JSON吗？
然后，可以使用此ID向用户验证 MegaSocialPlatform ，并将其链接到MegaSocialPlatform ID。
当然，诸如阻止黑客尝试超过20个密码的传统系统仍然存在。
会有任何安全问题吗？还有什么其他问题？
答案 0 :(得分：1)
如果双方同意，它可以通过这种方式实现，但缺点是：
MegaSocialPlatform会＆＃34;看到＆＃34;每个用户的CorporateCompany凭证，因此CorporateCompany必须对MegaSocialPlatform具有高度信任，不得存储或滥用其用户＆＃39;凭证 - 避免这正是OAuth的目的
用户不会遇到单点登录，但他们必须在使用MegaSocialPlatform时反复输入凭据，也可以跨不同平台（例如浏览器和原生应用）
双方需要就JSON对象中用户信息的表示达成一致 - 使用OpenID Connect等标准（主要是）避免这些成对协议）
请注意，CorporateCompany不必从头构建OAuth服务器，只需使用现有实施并根据需要进行配置。
答案 1 :(得分：1)
您没有明确说明，但我认为生成JSON（令牌）的API将在CorporateCompany中运行，并根据CorporateCompany的凭据存储对用户进行身份验证。您描述的基本上是安全令牌服务（STS）。
但是，为了让MegaSocialPlatform使用此令牌，它需要知道它所信任的实体发布的令牌。这是digital signatures发挥作用的地方。真正的STS将使用其私钥对令牌进行签名。使用STS的公钥配置使用服务，因此能够验证令牌是否由受信任的STS发出。
安全令牌通常包含更多信息。它们有效的日期/时间以及它们不再有效的日期/时间。它们还包含一个受众或信赖方标识符，用于指示令牌的用途，以防止使用MegaSocialPlatform为其他服务发出的令牌。
显然，客户端 - STS和客户端之间的所有通信 - MegaSocialPlatform必须通过加密通信通道（https）完成，因为承载令牌很容易被盗。
创建安全解决方案并非易事。因此，您应该避免实现自己的并使用来自信誉良好的源的标准协议和库或框架。 您可能需要查看JWT token以获取有关JSON格式的安全令牌的更多信息。