实施双腿OAuth提供商

我试图找到我的方法来解决OAuth规范,它的要求以及我能找到的任何实现,到目前为止,它似乎比它的价值更麻烦,因为我很难找到一个可以将它全部拉到一起的资源.或者也许只是因为我正在寻找比大多数教程更专业的东西.

我有一组现有的API - 一些是Java,一些是PHP - 我现在需要保护它,并且出于多种原因,OAuth似乎是正确的方法.不幸的是,我无法找到合适的资源来帮助我启动和运行提供商,这对该理论提出了挑战.由于大部分将是系统到系统的API使用,我需要实现一个两条腿的提供程序.考虑到这一点...

有谁知道用PHP实现一个2脚OAuth提供程序的任何好教程？

鉴于我有2种语言的安全API,我是否需要在两者中实现提供者,或者有没有办法将提供者创建为"前端控制器",我可以将所有请求汇集到一起？

例如,在保护PHP服务时,是否必须通过在每个API上包含必需的提供程序资源来单独保护每个API？

谢谢你的帮助.

罗布,不知道你在哪里登陆,但想加上我的2美分以防其他人遇到这个问题.

几个月前,我或多或少地提出了同样的问题,并且在一年中的大部分时间都听到了"OAuth".我正在开发一个我需要保护的REST API,所以我开始阅读OAuth ...然后我的眼睛开始向后滚动.

我可能给了它一个坚实的一天或两天的浏览和阅读,直到我决定,就像你一样,OAuth混淆了垃圾,只是放弃了它.

因此,我开始研究保护API的方法,并开始更好地掌握如何做到这一点.最流行的方式似乎发送带有校验一起请求到API 的整个消息(带有一个秘密,只有你和服务器知道编码),服务器可以用它来决定,如果该消息已被篡改它的方式来自客户端,如下:

客户端发送/user.json/123?showFriends=true&showStats=true&checksum=kjDSiuas98SD987ad

服务器获取所有这些,在数据库中查找用户"123",加载他的密钥然后(使用客户端使用的相同方法)在给定请求参数的情况下重新计算它的OWN校验和.

如果服务器生成的校验和与客户端发送的校验和匹配,则请求可以执行,如果不匹配,则认为它被篡改并被拒绝.

校验和称为HMAC,如果您想要一个很好的例子,它就是亚马逊网络服务使用的(他们称之为"签名"而不是"校验和").

因此,假设这个工作的关键组件之一是客户端和服务器必须以相同的方式生成HMAC(否则它们将不匹配),必须有关于如何组合所有参数的规则.然后我突然明白OAuth中所有"参数的自然字节排序"废话...它只是定义了如何生成签名的规则,因为它需要.

另一点是,您在HMAC生成中包含的每个参数都是一个值,当您发送请求时,该值不会被篡改.

因此,如果您只是将URI词干编码为签名,例如:

/user.json == askJdla9/kjdas + Askj2l8add

那么你的消息中唯一不能被篡改的是URI,所有的参数都可以被篡改,因为它们不是服务器重新计算的"校验和"值的一部分.

或者,即使您在计算中包含每个参数,您仍然存在"重放攻击"的风险,其中恶意中间人或被窃听者可以拦截API调用并且不断地将其重新发送到服务器.

您可以通过在HMAC计算中添加时间戳(始终使用UTC)来解决此问题.

提醒:由于服务器需要计算相同的HMAC,您必须发送您在计算中使用的任何值,除了您的秘密密钥(我认为OAuth称之为consumer_secret).因此,如果您添加时间戳,请确保发送时间戳参数以及您的请求.

如果您想使API免受重放攻击,您可以使用nonce值(它是服务器生成的一次性使用值,提供给客户端,客户端在HMAC中使用它,发送回请求,服务器确认然后在数据库中将nonce值标记为"used",并且永远不会让另一个请求再次使用它.

注意:'nonce'是解决"重放攻击"问题的一种非常精确的方法 - 时间戳很棒,但由于计算机并不总是具有同步时间戳值,因此必须允许服务器端的可接受窗口在我们接受或拒绝它之前,请求可能是多么"旧"(例如10分钟,30分钟,1小时......亚马逊使用15分钟).在这种情况下,您的API在整个时间段内在技术上都很脆弱.

我认为nonce值非常好,但是只需要在关键的API中使用它们以保持其完整性.在我的API中,我不需要它,但如果用户要求它稍后添加将是微不足道的......我只需要在我的数据库中添加一个"nonce"表,向客户端公开一个新的API,如:

/nonce.json

然后当他们在HMAC计算中将它发回给我时,我需要检查数据库以确保它以前从未使用过,一旦使用,在DB中将其标记为如此,如果请求EVER再次进入同样的nonce我会拒绝它.

摘要

无论如何,长话短说,我刚才所描述的一切基本上都是所谓的"双腿OAuth".没有额外的步骤流向授权客户端(Twitter,Facebook,Google等)授权客户端,该步骤被删除,而服务器隐含地信任客户端,如果他们发送的HMAC匹配.这意味着客户端具有正确的secret_key并使用它对其进行消息签名,因此服务器信任它.

如果您开始在线查看,这似乎是现在保护API方法的首选方法,或类似的方法.亚马逊几乎完全使用这种方法,除非他们在签署整个事件以生成HMAC之前对其参数使用稍微不同的组合方法.

如果你有兴趣,我会在我学习的过程中写下这整个旅程和思考过程.这可能有助于提供有关此过程的指导性思考.