如何在RESTful Web服务中实现登录?

时间:2011-01-05 19:13:05

标签: web-services web-applications rest login restful-authentication

我正在构建一个带有服务层的Web应用程序。服务层将使用RESTful设计构建。我们的想法是,未来一段时间我们可能会构建使用与Web应用程序相同的服务层的其他应用程序(iPhone,Android等)。我的问题是 - 如何实现登录?我想我无法从更传统的基于动词的设计转变为基于资源的设计。如果我用SOAP构建它,我可能会有一个名为Login的方法。在REST中我应该有一个资源。我很难理解如何为登录构建我的URI。它应该是这样的:

http://myservice/ {用户名} P = {}密码

编辑:前端Web应用程序使用传统的ASP.NET框架进行身份验证。但是,在身份验证过程中的某些时候,我需要验证提供的凭据。在传统的Web应用程序中,我会进行数据库查找。但在这种情况下,我正在调用服务而不是进行数据库查找。所以我需要服务中的一些东西来验证提供的凭据。除了验证提供的凭据之外,我可能还需要在用户成功通过身份验证之后获得某些信息 - 例如他们的全名,他们的ID等。我希望这会使问题更加清晰。

或者我没有以正确的方式思考这个问题?我觉得我很难正确地描述我的问题。

科里

6 个答案:

答案 0 :(得分:59)

正如S.Lott已经指出的那样,我们在这里有两个折叠的东西:登录和身份验证

身份验证超出了范围,因为这已得到广泛讨论,并且存在共识。但是,客户端实际需要为RESTful Web服务成功验证自身需要什么?对,某种令牌,我们称之为访问令牌。

客户端)所以,我需要的只是一个访问令牌,但如何获得这样的REST? 服务器)为什么不简单地创建它? 客户)怎么样?
服务器)对我来说,访问令牌只不过是一种资源。因此,我会为您创建一个以换取您的用户名和密码。

因此,服务器可以提供资源URL“/ accesstokens”,用于POST用户名和密码,返回到新创建的资源“/ accesstokens / {accesstoken}”的链接。 或者,您返回包含访问令牌和带有资源链接的href的文档:

<access-token
  id="{access token id goes here; e.g. GUID}"
  href="/accesstokens/{id}"
/>

最有可能的是,您实际上并未将访问令牌创建为子资源,因此不会在响应中包含其href。
但是,如果您这样做,客户端可以代表它生成链接吗?不!
请记住,真正的RESTful Web服务将资源链接在一起,客户端可以自行导航,而无需生成任何资源链接。

您可能遇到的最后一个问题是,您是应该将用户名和密码作为HTML表单或文档发布,例如XML或JSON - 它取决于......: - )

答案 1 :(得分:24)

您没有“登录”。你“认证”。差异世界。

您有很多身份验证替代方案。

HTTP Basic, Digest, NTLM and AWS S3 Authentication

  • HTTP基本和摘要式身份验证。这使用HTTP_AUTHORIZATION标头。这非常好,非常简单。但是会导致很多流量。

  • 用户名/签名验证。有时称为“ID和KEY”身份验证。这可以使用查询字符串。

    ?username=this&signature=some-big-hex-digest

    这就是像亚马逊这样的地方。用户名是“id”。 “密钥”是摘要,类似于用于HTTP摘要式身份验证的摘要。双方必须就摘要达成一致意见。

  • 某种基于cookie的身份验证。例如,OpenAM可以配置为代理进行身份验证,并提供RESTful Web服务器随后可以使用的cookie。客户端将首先进行身份验证,然后为每个RESTful请求提供cookie。

答案 2 :(得分:1)

很好的问题,很好地提出。我真的很喜欢帕特里克的回答。我使用像

这样的东西

- /用户/ {名} / loginsession

处理POST和GET。所以我发布了一个带有凭据的新登录会话,然后我可以通过GET将当前会话视为资源。

资源是登录会话,可能有访问令牌或授权码,到期等等。

奇怪的是,我的MVC调用者必须通过标头呈现密钥/不记名令牌,以证明它有权尝试创建新的登录会话,因为MVC网站是API的客户端。

修改

我认为这里的一些其他答案和评论是通过带外共享秘密来解决问题,并且仅使用标头进行身份验证。在许多情况下或服务到服务电话都很好。

另一种解决方案是流动令牌,OAuth或JWT或其他方式,这意味着&#34;登录&#34;已经由另一个进程发生,可能是浏览器中基于表单POST的正常登录UI。

我的答案是针对该UI背后的服务,假设您希望将登录和身份验证以及用户管理置于REST服务中而不是站点MVC代码中。它是用户登录服务。

它还允许其他服务进入&#34;登录&#34;并获得一个过期的令牌,而不是使用预共享密钥,以及CLI或邮递员中的测试脚本。

答案 3 :(得分:0)

自2011年以来发生了很大变化......

如果您愿意使用第三方工具,并略微偏离REST略微偏离Web UI,请考虑http://shiro.apache.org

Shiro基本上为您提供了一个用于身份验证和授权的servlet过滤器。您可以使用@ S.Lott列出的所有登录方法,包括基于表单的简单身份验证。

过滤需要身份验证的其余网址,Shiro将完成剩下的工作。

我目前正在自己​​的项目中使用它,到目前为止它对我来说效果很好。

这是人们可能感兴趣的其他内容。 https://github.com/PE-INTERNATIONAL/shiro-jersey#readme

答案 4 :(得分:0)

首先要了解REST是它基于令牌的资源访问。与传统方式不同,访问是基于令牌验证授予的。简单来说,如果你有正确的令牌,你可以访问资源。现在还有很多其他的东西用于创建和操纵令牌。

对于第一个问题,您可以设计Restfull API。凭据(用户名和密码)将传递到您的服务层。然后,服务层验证这些凭据并授予令牌.Credentials可以是简单的用户名/密码,也可以是SSL证书。 SSL证书使用OAUTH协议,更安全。

你可以像这样设计你的URI- 令牌请求的URI-&gt; http://myservice/some-directory/token? (您可以在此URI中传递Credentilals for Token)

要将此令牌用于资源访问,您可以将此[授权:承载(令牌)]添加到您的http标头。

客户可以使用此令牌访问服务层的不同组件。您还可以更改此令牌的到期时间以防止滥用。

对于第二个问题,您可以做的一件事是您授予不同的令牌来访问服务层的不同资源组件。为此,您可以在令牌中指定resource参数,并根据此字段指定grand权限。

您也可以点击这些链接获取更多信息 - http://www.codeproject.com/Articles/687647/Detailed-Tutorial-for-Building-ASP-NET-WebAPI-REST

http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api

答案 5 :(得分:-4)

我之前遇到过同样的问题。登录不能很好地转换为基于资源的设计。

我通常处理它的方法是通过登录资源并在参数字符串上传递用户名和密码,基本上是

http://myservice/login?u= {username}&amp; p = {password}

上获取

响应是某种会话或auth字符串,然后可以传递给其他API进行验证。

在登录资源上执行GET的替代方法是执行POST,REST现实主义者可能不会喜欢我:),并传入正文中的信用卡。答案是一样的。