REST Web服务的身份验证

Question

REST Web服务的身份验证

use*_*799 43 openid authentication rest web-services oauth

我开始设计REST Web服务,并且不清楚最佳的身份验证方法.该服务将允许个人用户访问/管理他们自己的数据,因此需要某种类型的用户身份验证.我一直在看这些选项:

OAuth的

OAuth似乎更多的是授权而不是身份验证.我计划在服务中本地处理授权,所以我不是在寻找解决方案.但是,OAuth是否也适用于身份验证？

OpenID的

OpenID当然提供了身份验证的解决方案,但这更适合允许用户使用他们的第三方凭据(谷歌,雅虎等)虽然我想支持这一点,但这不是我主要关注的问题,我会绝对允许用户使用本机凭据(电子邮件/密码)注册.

HTTP基本身份验证

这很容易实现,但我的理解是,这可能不是一个非常安全的方法.此外,似乎需要为每次访问交换凭据,但我更希望用户进行一次身份验证,然后通过会话令牌继续访问.

自定义验证

基本上,滚动我自己的登录/令牌生成服务,并需要一个有效的令牌来访问所有其他资源(显然,一切都将通过SSL).

除了创建Web服务之外,我还将构建一个代表用户使用这些服务的客户端(Web)应用程序,但我不希望应用程序必须存储用户信息/凭据等.所以,像这样:

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

而且,我想让其他人也建立客户端,所以中间层可以是任何第三方应用程序:

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

我的顶级要求是:

安全(显然)
本机凭据
支持第三方凭据(谷歌,雅虎,LinkedIn等)
支持多个客户端(Web应用程序,移动应用程序,第三方应用程序等)
客户端凭据(只是应用程序ID？)
到期的登录会话
不需要授权

所以,我的问题是,基于上述情况(如果这太模糊,请告诉我),是否有"最佳"方法？OAuth或OpenID是否合适,或者我是否过于复杂,而应该只使用自己的身份验证？

编辑:

我想我需要实现以下内容:

1)原生凭证/令牌(通过SSL进行HTTP基本身份验证？)

2)OpenID"依赖方"允许我的api使用其他地方托管的OpenID(即"支持第三方凭证")

3)OAuth"Consumer"允许我的api访问第三方服务(比如访问用户的LinkedIn个人资料).

4)一个OpenID"提供者",允许人们在别处使用api的本地ID(可选)

5)OAuth"提供商"允许第三方应用代表用户访问我的API(可选)

这看起来是对的,还是我让它变得比它需要的更复杂？

Answer 1

小智 12

您可以考虑使用JWT(JSON Web Token)查看JWT草案rfc.它肯定会满足您的安全性和会话到期要求.然而,作为草案标准,它现在不太可能被广泛使用,这可能会很快改变,因为JWT是OAuth 2.0的一部分.JWT很容易在大多数语言中实现,并且已经有很多库.作为一个简单的解释,JWT令牌由3个部分组成,即标题,正文和签名.标题和正文是json对象,它们是basee64url编码的(字母表与base64的2个最后字符不同),然后用HMAC256(或标题中指定的其他算法)签名,RFC解释了如何准确生成此签名.您可能想要检查此在线令牌生成器.

JWT是http标头和查询参数友好.

Answer 2

Anu*_*ndy 11

要考虑的一个好选择是"共享密钥身份验证".这是Amazon Web服务和Windows Azure存储服务使用的身份验证类型.我们在我们开发的REST服务中使用了共享密钥身份验证.您可以在Google上快速搜索"共享密钥身份验证",您将获得大量详细信息.

我在这里写了一篇关于此的博客文章.

高级步骤是:

客户端组合了REST服务定义的一组唯一数据(元素).
使用仅为客户端和REST服务所知的密钥对此组合数据进行签名
将此签名作为HTTP标头的值发送到REST服务
REST服务以与客户端完全相同的方式计算签名
将客户端发送的签名与计算的签名进行比较,如果相同则假设其有效请求,否则拒绝该请求

Answer 3

Aru*_*asR 7

我的建议是验证第一个请求,然后设置会话令牌.

前端应用程序将存储令牌并为每个后续请求提供令牌.

令牌将具有到期时间.如果在特定时期内未使用令牌,则令牌将过期.

令牌可以与始发IP地址相关联以增加安全性.

令牌可以作为cookie传输,也可以作为URL中的查询参数之一传输.

如果可以接受SSL客户端身份验证的麻烦,则可以使用相互SSL身份验证.必须为每个客户端配置服务器信任的证书.如果您必须以不同方式对待客户,它可以是相同的证书,也可以是不同的证书.

@Shawn username / pwd是用户的身份验证凭据。会话令牌是一次性到期的随机数据。每次可以发送用户名/密码时，为什么需要令牌？这样您就不必多次存储和传输用户凭据。用户名和密码敏感，应使用昂贵的哈希算法进行保护。您希望尽可能少地存储和传输它们，以防第三方获取它们。会话令牌是临时的，即使被拦截也不会永久损害安全性。 (2认同)

Answer 4

Jos*_*nke 2

根据您的要求，我认为OAuth 2.0实际上可能是一个有趣的选择。OAuth确实是一个授权协议，但它也是带有和Authenticates的客户端。您可以使用并选择不包含，这样用户就有一个，它会在一定时间后过期。由于 OAuth 是一种广泛使用的协议，因此它们已经有许多客户端和服务器端库供您和您的客户使用。clientIdclientSecretClient Credential FlowRefresh TokenAccess Token

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

有关更多信息，您还可以查看我之前针对类似问题给出的其他答案：/sf/answers/1050264421/

归档时间：	11 年，12 月前
查看次数：	53484 次
最近记录：	6 年，2 月前