RESTful WCF 4 服务中移动客户端的用户身份验证

发布于 2024-12-07 11:41:07 字数 365 浏览 0 评论 0原文

我正在尝试开发一个供移动客户端(目前是 iOS 客户端)使用的 Web 服务,我读到 RESTful 服务比 SOAP 服务轻量得多,所以我想尝试一下。

大多数方法都需要身份验证,但我不确定如何处理这个问题,因为我读到 REST 应该是无状态的,所以我如何验证从 iOS 访问服务的用户,然后使用该身份验证来验证对其他方法的连续调用网络方法?

注意:我将使用 IIS 上的 WCF 4 WebHttp

谢谢你!

I'm trying to develop a web service to be consumed by mobile clients (iOS clients, for now), I read that RESTful services are much more lightweight than SOAP services, so I'd like to try my hand at this.

Most methods will require authentication, but I'm not sure how to handle this, as I read REST is supposed to be stateless, so how can I validate the user accessing the service from iOS and then use that authentication to validate successive calls to other web methods?

Note: I'll be using WCF 4's WebHttp on IIS.

Thank you!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

撩起发的微风 2024-12-14 11:41:07

有许多相当成熟的模式可以做到这一点。

  • 最简单的方法是提供用户名:密码作为授权标头或请求的一部分(查询字符串/表单数据)。这将要求您在每次调用时对用户进行身份验证/授权。也许这对你来说并不理想,但如果你使用的是 WebHttp(如果你不是这个意思,我会认真看看 WCF Web Api),在 WCF 通道堆栈中构建 HttpModule 或其他内容来拦截调用并对用户进行身份验证将相当容易。
  • 一种非常常见的方法是公开一个采用 user:password 并生成 API 令牌的端点。然后,用户获取该 API 令牌并使用它来验证后续调用。该令牌可以是任何内容,从弱加密数据到由共享密钥、HTTP 动词、请求的资源等组成的哈希值。如果您在 google 中搜索“HMAC 身份验证”,您会发现几个这样的示例。 Azure 的身份验证方案 是真正细粒度令牌的示例。这种方法的好处是,您有一个端点涉及身份验证和构建令牌,而其他端点只需要知道如何验证哈希或解密令牌;很好的关注点分离。
  • 如果您希望 API 的使用者是第三方应用程序,那么 OAuth/OAuth2 几乎是事实上的标准。

There are a number of fairly established patterns for doing this.

  • The simplest way to do so would be to provide the username:password as an Authorization header or part of the request (querystring/form data). This would require you to authenticate/authorize the user on each call. Not ideal for you, perhaps, but if you're using WebHttp (if you didn't mean this, I'd take a serious look at WCF Web Api), it would be fairly easy to build an HttpModule or something in the WCF channel stack to intercept the calls and authenticate the user.
  • A very common way is to expose an endpoint that takes user:password and generates an API token. The user then takes that API token and uses it to authenticate subsequent calls. That token can be anything from weakly-encrypted data to a hash consisting of a shared secret key, the HTTP verb, requested resource, etc. You'll find several example of this if you google "HMAC Authentication". Azure's authentication schemes are an example of a really granular token. The nice thing about this approach is that you have one endpoint concerned with authentication and building the tokens, and your other endpoints just need to know how to validate the hash or decrypt the token; a nice separation of concerns.
  • OAuth/OAuth2 are pretty much the de facto standard if you expect your API's consumer to be a third-party application.
稚气少女 2024-12-14 11:41:07

我建议使用类似于 OAuth 的策略。您将专门编写一项服务来验证凭据并分发访问令牌,并且对 API 的任何请求都需要有效的访问令牌。

如果您在 IIS 中托管,我会在使用 HttpModule 检查所有传入请求是否有有效令牌之前完成此操作。如果没有,模块只会以 401 Unauthorized Http 状态代码结束请求。

编辑:

如果您想在每个操作的基础上进行更细粒度的授权,我建议使用自定义授权策略。查看 http://msdn.microsoft.com/en-us/library/ms731181 .aspx 了解更多详细信息。

I would suggest using a strategy similar to OAuth. You would write one service specifically to validate credentials and hand out access tokens, and require a valid access token for any request to your API.

If you're hosting in IIS, I've accomplished this before using an HttpModule to inspect all incoming requests for a valid token. If there isn't one, the module just ends the request with a 401 Unauthorized Http status code.

EDIT:

If you'd like to do more fine-grained authorization on a per operation basis, I'd suggest using a custom authorization policy. Check out http://msdn.microsoft.com/en-us/library/ms731181.aspx for more details.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文