php - 是否可以在没有 javascript 的情况下实现 Oauth 2.0？

Question

在我的电子商务网站上，我为用户提供了 openid 登录名。除 facebook 外，所有主要提供商都提供了一个 openid 端点。Facebook 仅提供 oauth 2.0。

对于那个异常(exception)，我自己设置了一个 openid 端点，用户可以在其中使用 facebooks oauth 登录。

换句话说，我创建了一个中间站点，用户可以在其中使用 facebook 登录，然后从那里使用 openid 无缝登录到我的电子商务站点。这仅涉及 header 重定向并且对最终用户透明。

现在亚马逊joined the league单点登录提供商。它们仅支持 oauth 2.0。

总而言之，oauth 2.0 似乎是获胜的候选者而不是 openid，因为我关心的所有提供商现在也都支持 oauth。

所以我考虑直接在我的电子商务网站中实现 oauth。

但是，实现说明因提供商而异。

大多数需要将外部 javascript 加载到站点中。为我想要支持的每个 oauth 提供商加载外部 javascript 是我想避免的选项。

Facebook 提供完全服务器端的方式，不涉及 javascript。

亚马逊没有。

但这全是 oauth 2.0，不是吗？

在我看来，标准要么非常宽松，要么没有得到一致实现。

是否可以有一个通用的 oauth 2.0 类，我只需传递特定于提供者的配置和端点并实现登录？

我查看了 Zend 实现，但它确实非常庞大...facebook 的无 javascript 实现真的很小...

我有点迷路了。有人可以指出我正确的方向吗？

我想实现几个 oauth 提供程序。其中肯定有 google、facebook、amazon 和 twitter。

是否可以使用相同的代码库实现这一点，还是我必须使用它们的 sdk 类和 javascript 单独实现它们？

我可以毫无问题地做到这一点，但出于多种原因(维护、灵 active 、添加新 vendor 等)，我的内心真的不喜欢它

oauth 2.0 标准在哪里？

欢迎提供任何帮助。

个人旁注

I apologize for taking this chance to briefly point out that I don't like Oauth. It requires every site that uses it to register with the oauth providers. Also those providers may disagree to cooperate with sites. I do not like that authority, I prefer openid. I know its not perfect, but I prefer it. Also openid and oauth are vulnerable by design for an attack where a malicious sites lets the user click the login button and opens up a spoofed provider side, where the user logs in in believe that he is logging into the provider site. It cant be helped, the user has to look at the url to see whether its realy the desired site. I know that this is a fundamental problem and difficult to handle, however I wanted to point it out.

Answer 1

提供商之间有很多相似之处，基本流程也相同。浏览器中通常不需要任何 Javascript。每个提供者为您提供的只是一个 helper ，让您的事情变得更轻松(如果您只关心他们的话)。

看来您正在制作一个网站。为此，您需要实现的 OAuth 2 流程称为授权代码流程。最重要的是，它只是一些遵循非常相似模式的 http(s) 请求:

1. 将用户重定向到提供商
2. 登录和同意页面
3. 使用 code 重定向回您的站点(到注册的回调地址)
4. 您的网站请求 access_token来自提供商，使用 code从步骤 #3 和一个 client_id/client_secret (本质上是您的网络服务器的凭据。
5. 使用access_token在 #4 中获取以调用提供者 API。

我已经写过它了here如果您想查看更多详细信息。它在 product 的上下文中我正在努力，但原则是一样的。

事情通常变得有点复杂的地方是:

• 权限scope ，这从一个提供者到另一个提供者是不同的。例如:Facebook 有很多选项，可以非常精细地控制您要求用户披露的内容(例如 friend 、照片等)。 LinkedIn 更少(例如个人资料、您的网络、通知)。亚马逊只有两个(姓名，邮政编码)。

这些都是非常特定于提供商的，因为它们与他们管理的资源相关。请注意，OAuth 本质上是一个授权 协议(protocol)(通常用于身份验证)。在许多情况下，如果您不打算调用他们的 API，您可以使用最小范围。

• 用户个人资料信息。大多数提供商都有 /userprofile端点以检索登录用户的属性。但很多时候，每个人通常实现不同的模式:有些使用 email其他人会称之为 emailaddress .与 last_name 相同对比family_name等等。将配置文件规范化为具有通用语义的内容取决于您。

对于我们的系统，我们选择将所有内容映射到 openid connect用户信息 standard claims在可能的情况。并非总是可能，因为提供商通常会提供更多信息。 (Here's 我们实际供应的)

关于您的旁注:您是对的，始终使用 SSL 的充分理由。这也是一些提供商添加多因素身份验证的原因。