如何为我的 Web API Web 服务实现身份验证和授权？答案

【问题标题】：How to implement Authentication and Authorization for my Web API web service?如何为我的 Web API Web 服务实现身份验证和授权？
【发布时间】：2013-04-09 11:26:02
【问题描述】：

我有一个 Web API Web 服务，许多客户端应用程序使用该服务使用不同的技术，如 Java、.NET 等。因此，我的用户凭据是存储在单独的数据库中。

我的 Web 服务托管在 IIS 中，并且我已在服务器端配置并启用 SSL，以确保请求/响应消息经过加密和签名。

我还配置了 IIS 的 IP 地址限制功能，以允许来自少数已知 IP 地址的请求。

我不喜欢使用 基本身份验证，因为它会在每条消息中以纯文本形式发送凭据，尽管消息是使用 SSL 加密的。

显然，我无法使用集成 Windows 身份验证，因为我的用户与我的服务器不在同一个域中。

我无法使用 表单身份验证，因为我的客户端不是基于浏览器的。

那么，为我的 Web 服务实施身份验证和授权的最佳方式是什么？

我在想一种方法是提供一个 Authenticate(username, password) web 方法，它的行为类似于 Identity Provider/Security-token-service 并生成一个特定于该用户的令牌，该令牌在特定时间后过期。然后客户端必须在每个 Web 方法请求中发送身份验证令牌，我通过为我的控制器创建自定义授权过滤器来确保它。

这种方法的优点是用户不必在每个请求中都发送用户名/密码，而只需发送一个临时令牌。缺点显然是管理令牌寿命；什么时候到期？例如如果在一小时内没有提出请求。

为我的网络服务实施身份验证和授权的最佳方式是什么？

【问题讨论】：

如果会话受 SSL 保护，那么数据不会完全以明文形式发送，对吧？ :-)

标签： asp.net-mvc web-services security asp.net-web-api

【解决方案1】：

我将在我的 cmets 中解决与 SOAP 服务相关的身份验证选项。授权是在服务器应用程序中实现的，并且与选择的身份验证类型几乎无关。 Web 服务分为三 (3) 类： -私人的 -社区 -公开

听起来您提供的网络服务是一项社区服务，因为它只提供给受信任的合作伙伴。我知道这一点，因为您解释说在 IIS 中配置了 IP 地址限制。包括 IP 地址限制是实现安全 Web 服务的众多良好措施之一。安全不是一个单一的东西。它是许多防御的积累。 IP 地址限制是一个好的开始。

Web 服务本质上是无状态的。因此，在调用 Web 服务时，通常必须在每个请求中包含凭据（用户名和密码）。所以，这不是问题或担忧。

HTTP 基本身份验证不是一个糟糕的选择。它受到所有客户端和服务器应用程序的支持，并且易于实现。我喜欢将 HTTP 基本身份验证视为最低公分母。我不会排除它。 HTTP 基本身份验证在 http 标头中以纯文本形式包含凭据，因此始终建议包含 SSL (HTTPS) 以加密传输通道。

WS-Security 是一种非常常见的 Web 服务授权标准。它是 Web 服务的行业标准，该规范由结构化信息标准促进组织 (OASIS) 组织发布。 WS-Security 包括一个用于包含用户名/密码的 UsernameToken 配置文件。 WS-Security 块被添加到 SOAP 消息的头部。相比之下，HTTP 基本身份验证被添加到 HTTP 标头中。 HTTP 基本身份验证附加到传输协议。相比之下，WS-Security 附加到 SOAP 消息。 WS-Security UsernameToken 是纯文本格式，因此始终建议包含 SSL (HTTPS)。

另一个选项是客户端证书身份验证。此选项使用数字证书代替用户名/密码作为身份验证令牌。此方法效果很好，但要求 Web 服务团队成员和客户端应用程序团队成员都熟悉 SSL 数字证书作为先决条件。此方法的学习曲线高于其他方法。

您描述的自定义解决方案不是必需的，因为存在许多行业标准来实施和解决您寻求的解决方案。例如，如果您在 Web 服务中实现 WS-Security，则不必向客户端应用程序团队提供文档并解释如何在他们的客户端应用程序中实现它。 WS-Security 是一个行业标准，目前大多数现代 SOAP 服务器和 SOAP 客户端都有很好的文档记录和支持。这同样适用于 HTTP 基本身份验证。

我希望这会有所帮助。干杯，DCova

【讨论】：

【解决方案2】：

IP 地址很容易被欺骗，因此不要依赖它们来保护您的服务。

我建议您只允许通过 HTTPS 进行访问，为了进一步保护它，请验证用于签署请求的证书。更好的是，拥有自己的证书服务器并为此目的颁发自己的证书。

【讨论】：

【解决方案3】：

在 facebook 中，它们向应用程序提供访问令牌，该令牌仅在更改密码或用户特别取消对应用程序的授权时才会更改。你们很多人考虑这种方法。这在 Google 的 Map API 中也是类似的。我能想到的唯一安全的方法是检查请求来自哪里（请求的 IP 地址），然后检查 apikey 然后响应。

【讨论】：

在用户密码更改时更改令牌听起来是个好方法。然而，依赖远程 IP 地址绝不应该被认为是非常安全的。

【解决方案4】：

我的 Web 服务托管在 IIS 中，我已在服务器端配置并启用 SSL，以确保请求/响应消息经过加密和签名。

SSL 是传输安全而非消息安全。它不会为您签署消息。它对通道进行加密。

我觉得预共享密钥或 API 密钥的方法最适合您的情况。由于用户有用户名和密码，我假设他们在某个地方注册。作为该过程的一部分，生成一个密钥，该密钥可以是共享对称密钥，即双方（客户端和服务器）具有相同的密钥。客户端在某些自定义方案的 Authentication 标头中发送用户 ID，以及请求消息的特定部分的 SHA256 哈希。服务器获取用户 ID，检索密钥，计算消息相同部分的哈希值，如果哈希值匹配，则客户端进入。

看看我的书Pro ASP.NET Web API Security。

【讨论】：