有许多大型组织已经这样做了,我很遗憾没有看到这个问题的其他答案,因为它是一个如此重要的网络模式。
我将假设您不会从头开始滚动自己的 OAuth 2.0 提供程序,如果您这样做的话 - 做得好,否则您应该使用像Doorkeeper这样的工具来为您做这件事。
现在,在 OAuth 2.0 中,您拥有以下实体:
- 在您的网站上注册的用户
- 在您的网站上注册的应用程序(订阅您的 oauth2)
- 用户权限,这是用户“允许”的应用程序列表
- 开发人员(正在使用您的身份验证 API/小部件并构建应用程序)
首先要注意的是您必须有一个与每个应用程序相关联的域名。因此,如果开发人员在您的网站上注册 API 令牌/机密,他创建的应用程序将映射到唯一域。
现在,我认为应用程序通过您的网站对用户进行身份验证的流程已经很清楚了。话虽这么说,你不需要做太多的工作。
当应用程序将用户发送到您的网站(以便登录)时,您会在用户的计算机上放置一个会话 cookie。让我们称之为“Cookie-X”。
现在用户已通过您的网站的身份验证并返回到应用程序。在那里,我们想要显示一个自定义小部件,其中包含与该用户有关的信息。
开发人员需要将一些代码复制粘贴到此应用程序中。
流程是这样的:
该代码将包含一个指向您网站的 URL,其中包含他在您的网站上注册他的应用程序时获得的应用程序 ID(不是秘密)。
当该代码运行时,它将使用他的 appId ping 您的网站。您需要使用您的数据库检查该 AppID,并另外检查引荐来源网址是否来自与在您的网站中为该 AppID 注册的域名相同的域。编辑:或者或另外,代码可以检查document.domain
并将其包含在对您网站的 ping 中,允许您验证请求是否来自已使用给定 AppID 注册的域。
如果这是正确的,你会回复一些 JS 代码。
您的 JS 代码会查找您的网站在用户登录时设置的会话 cookie。如果找到该 cookie,它会通过会话 ping 回您的网站,并且您的网站会使用自定义视图内容进行响应。
编辑:正如评论中正确提到的,cookie 应该是 HttpOnly 以防止常见的 XSS 攻击。
补充说明
这是一种安全方法的原因:
AppId 和域名是一个足够好的组合来验证其他人没有获取此信息。即使 appId 在应用程序 html 源代码中可见,域名也必须被任何试图使用其他人的 AppID 的人欺骗。
假设某人获取了一个不是他的 AppID,并在请求您的小部件时编写代码来欺骗引用者的域名,他仍然无法看到任何信息。由于您正在显示用户特定信息,因此只有当您的网站可以找到它放置在用户浏览器上的会话 cookie 时,该小部件才会呈现,而该会话 cookie 不能真正被欺骗。有诸如会话劫持等方法。但我认为这超出了这个问题的范围。
其他方法
只需查看 Facebook 的社交插件,您就可以知道还有其他选择。
例如,可能是使用 Iframe。如果你要求开发者在他的应用程序中添加一个 iframe,你甚至可以减少上面提到的一些步骤。但是您必须将 JS 连同它一起添加(在 iframe 之外)以获取正确的域等。当然,从可访问性和界面的角度来看,我不太了解 iframe。