Fatal编程技术网

Web services RESTWeb服务的身份验证

web-services rest authentication oauth openid

Web services RESTWeb服务的身份验证,web-services,rest,authentication,oauth,openid,Web Services,Rest,Authentication,Oauth,Openid,我正在开始设计REST web服务，但还不清楚最好的身份验证方法。该服务将允许个人用户访问/管理他们自己的数据，因此需要某种类型的用户身份验证。我一直在考虑这些选项： 非统组织 OAuth似乎更多的是授权，而不是身份验证。我计划在服务中以本机方式处理授权，因此我不寻求解决方案。但是，OAuth也适用于身份验证吗 OpenID OpenID当然为身份验证提供了一个解决方案，但它更适合于允许用户使用他们的第三方凭据（Google、Yahoo等）。虽然我想支持这一点，但这不是我主要关心的问题，

我正在开始设计REST web服务，但还不清楚最好的身份验证方法。该服务将允许个人用户访问/管理他们自己的数据，因此需要某种类型的用户身份验证。我一直在考虑这些选项：

  • 非统组织
OAuth似乎更多的是授权，而不是身份验证。我计划在服务中以本机方式处理授权，因此我不寻求解决方案。但是，OAuth也适用于身份验证吗

  • OpenID
OpenID当然为身份验证提供了一个解决方案，但它更适合于允许用户使用他们的第三方凭据（Google、Yahoo等）。虽然我想支持这一点，但这不是我主要关心的问题，我肯定会允许用户使用本机凭据（电子邮件/密码）注册

  • HTTP基本身份验证
这很容易实现，但据我所知，这可能不是一种非常安全的方法。此外，似乎需要为每次访问交换凭据，但我更希望用户验证一次，然后通过会话令牌继续访问

  • 自定义身份验证
基本上，使用我自己的登录/令牌生成服务，并需要一个有效的令牌来访问所有其他资源（显然，所有内容都将通过SSL）

除了创建web服务外，我还将构建一个客户端（web）应用程序，它代表用户使用这些服务，但我不希望应用程序必须存储用户信息/凭据等。因此，类似以下内容：

用户（使用电子邮件/密码或第三方凭据进行身份验证） -->Web应用程序（使用应用程序ID进行身份验证） -->网络服务

同样，我希望允许其他人也构建客户端，因此中间层可以是任何第三方应用程序：

用户（使用电子邮件/密码或第三方凭据进行身份验证） -->第三方应用程序（使用应用程序ID进行身份验证） -->网络服务

我的最高要求是：

  • 安全（显然）
  • 本机凭据
  • 支持第三方凭据（谷歌、雅虎、LinkedIn等）
  • 支持多个客户端（web应用、移动应用、第三方应用等）
  • 客户端凭据（只是一个应用程序ID？）
  • 过期的登录会话
  • 不需要授权
因此，我的问题是，基于上述情况（请让我知道这是否太模糊），是否有“最佳”方法？OAuth或OpenID是否合适，或者我是否把它弄得太复杂了，应该只使用我自己的身份验证

编辑：

我认为我需要实施以下措施：

1） 本机凭据/令牌（通过SSL的HTTP基本身份验证？）

2） 一个OpenID“依赖方”，允许我的api使用托管在别处的OpenID（即“支持第三方凭据”）

3） OAuth“消费者”，允许我的api访问第三方服务（如访问用户的LinkedIn配置文件）

4） 一个OpenID“提供者”，允许人们在其他地方使用api的本机ID（可选）

5） OAuth“提供者”，允许第三方应用程序代表用户访问我的api（可选）

这似乎是对的，还是我让它变得比需要的更复杂了？

基于您的需求，我认为
OAuth 2.0
实际上可能是一个有趣的选择。OAuth确实是一种授权协议，但它也使用
clientId
和
clientSecret
对客户机进行身份验证。您可以使用
客户端凭证流
，并选择不包括
刷新令牌
，这样用户就拥有一个
访问令牌
，该令牌在一定时间后过期。由于OAuth是一种广泛使用的协议，它们已经有许多客户端和服务器端库供您和您的客户端使用

如果您认为OAuth对于您的应用程序来说太重或太复杂，我可能会坚持使用
Basic Authentication
而不是
HTTPS
。但正如我在另一个类似问题的答案中所说，我永远不会发明自己的身份验证机制

对于更多的信息，您还可以看一下我前面给出的类似问题的另一个答案：

< P>一个很好的选择是“共享密钥认证”。这是Amazon web服务和Windows Azure存储服务使用的身份验证类型。我们在开发的REST服务中使用了共享密钥身份验证。你可以在谷歌上快速搜索“共享密钥认证”，你会得到很多详细信息

我写了一篇关于这个的博客文章

高级步骤包括：

  • 客户机组合了一组由REST服务定义的唯一数据（元素）
  • 使用只有客户端和REST服务知道的密钥对该组合数据进行签名
  • 将此签名作为HTTP头的值发送到REST服务
  • REST服务计算签名的方式与客户端完全相同
  • 比较客户端发送的签名和计算的签名，若相同，则假定其为有效请求，否则拒绝该请求
    • 您可以使用HTTP Basic Auth，其中传输的密码实际上不是一个密码，而是一个令牌，客户端在不同的资源请求中获取该令牌，他/她/它必须提供他/她/它的密码一次，而且只能提供一次（甚至可能通过不同的通道）。这不会保护中间人攻击（因为没有消息签名），但其思想是，您可以始终要求客户端以某种方式（即在您自己的身份验证服务上）生成动态令牌，然后让它将该令牌作为密码替换发送，这样实际密码就不会通过网络不断传输。 是的，这看起来像是一个“自定义身份验证解决方案”，但实际上并不是因为你可以强加任何规则