REST Web服务的身份验证
我开始设计一个REST Web服务，并且对最佳认证方法还不清楚。 该服务将允许个人用户访问/管理自己的数据，因此需要某种类型的用户身份验证。 我一直在看这些选项：
OAuth似乎更多地是关于授权而不是认证。 我计划在服务中本地处理授权，所以我不在寻找解决方案。 但是，OAuth是否也适用于身份验证？
OpenID当然提供了一个认证解决方案，但是这更多的是允许用户使用他们的第三方证书（谷歌，雅虎等）。虽然我想支持这个，但这不是我主要关心的，我会绝对允许用户使用本机凭据（电子邮件/密码）注册。
这很容易实现，但我的理解是，这可能不是一个非常安全的方法。 此外，它似乎需要每次访问的凭证交换，但我更希望用户验证一次，然后通过会话令牌继续访问。
基本上，推出我自己的登录/令牌生成服务，并需要一个有效的令牌来访问所有其他资源（显然，一切都将通过SSL）。
除了创建Web服务外，我还将构建一个代表用户使用这些服务的客户端（Web）应用程序，但我不希望应用程序必须存储用户信息/凭证等。 所以，像这样的东西：
用户（使用电子邮件/密码或第三方凭证进行身份验证） - > Web应用程序（使用应用程序ID进行身份验证） - > Web服务
再次，我想让其他人也可以构建客户端，因此中间层可以是任何第三方应用程序：
用户（使用电子邮件/密码或第三方凭据进行身份验证） - >第三方应用程序（使用应用程序ID进行身份验证） - > Web服务
我的顶级要求是：
所以，我的问题是，基于上述（请让我知道这是否太模糊），是否有“最好”的方法？ OAuth或OpenID是否合适，还是我这样做太复杂了，而应该推出自己的身份验证？
编辑：
我想我需要实施以下内容：
1）原生凭证/令牌（基于SSL的HTTP基本身份验证？）
2）OpenID“依赖方”允许我的api使用别处托管的OpenID（即“支持第三方凭证”）
3）OAuth“消费者”，允许我的api访问第三方服务（如访问用户的LinkedIn个人资料）。
4）OpenID“Provider”，允许用户在其他地方使用api的本地ID（可选）
5）允许第三方应用代表用户访问我的api的OAuth“Provider”（可选）
这看起来是对的吗，还是我把它做得比它需要的更复杂？
你可以考虑JWT（JSON Web Token），参见JWT draft rfc。 它肯定会满足您的安全和会话到期要求。 然而，作为一个标准草案，它现在不太可能被广泛使用，这可能会很快发生变化，因为JWT是OAuth 2.0的一部分。 JWT很容易在大多数语言中实现，并且已经有很多库。 作为一个简单的解释，一个JWT令牌由3部分组成，头部，主体和签名。 标头和正文是被basee64url编码的json对象（字母与base64的最后两个字符不同），然后用HMAC256（或标头中指定的另一个算法）签名，RFC解释了如何准确生成该签名。 您可能需要检查此在线令牌生成器。
JWT是http头和查询参数友好的。
“共享密钥验证”是一个很好的选择。 这是亚马逊网络服务和Windows Azure存储服务使用的身份验证类型。 我们在我们开发的REST服务中使用了共享密钥认证。 您可以在Google中快速搜索“共享密钥身份验证”，您将获得大量细节。
我在这里写了一篇博文。
高层次的步骤是：
我的建议是验证第一个请求，然后设置会话令牌。
前端应用程序将存储该令牌并为其提供每个后续请求。
该令牌将具有到期时间。 如果在某段时间内未使用，令牌将过期。
该令牌可以与始发IP地址相关联以增加安全性。
令牌可以作为cookie传送，也可以作为URL中的查询参数之一传送。
如果SSL客户端身份验证的麻烦是可以接受的，则可以使用相互SSL身份验证。 每个客户端都必须配备服务器信任的证书。 它可以是相同的证书，也可以是不同的证书，如果你必须以不同的方式处理客户。
链接地址: http://www.djcxy.com/p/33783.html