目前比较成熟的Web服务认证方式有HTTP认证、自定义认证、采用现有工具包。
利用Web服务可以建立面向服务的架构（SOA，Service-oriented architecture），即不用改变应用，利用Web服务的消息驱动机制，让分布式系统协同工作。
安全的Web服务需要保证以下5项安全性要求：
a.认证：提供某个实体（人或者系统）的身份的保证
b.授权：保护资源以免对其进行非法的使用和操作
c.机密性：保护信息不被泄漏或暴露给未授权的实体
d.完整性：保护数据以防止未授权的改变、删除或替代
e.不可否认性：防止参与某次通信交换的一方事后否认本次交换曾经发生过。
在实际应用中，完整的满足上述 5 项要求对于普通的 Web 服务应用太过复杂，同时也太浪费资源。目前 Internet 上的公共 Web 服务，对于一般的安全性要求，只需满足上述 1、2 两项要求即可。对于授权，也是通过认证后的用户身份，进行相应的权限分配。

1、HTTP认证

对于公共的 Web 服务，可以采用和 HTTP 服务一样的集中安全方式，包括基本(Basic)、摘要(Digest)、集成(Integrated)和基于证书的(Client Certificate)的认证机制。

1.1 基本认证(Basic)

基本认证是服务器直接验证客户端提供的明文用户名和密码是否和保存的用户信息相匹配的，如果匹配则通过认证。其优点是算法最简单，资源占用少，认证只需要 1 个来回；缺点是不安全，密码是经过简单的 Base64 编码明文传送，如果需要安全性则需要采用安全套接层协议 HTTPS。

1.2 摘要认证(Digest)

比基本认证稍微难一点实现，但也只需要一个来回的认证。密码不再是明文传送，而是传送密码及其他信息综合后生成的哈希值，因此这种认证方式不需要传送加密。它的优点是密码不用明文传输，比较安全；服务器端可以通过一定的哈希值生成算法在一定程度上抵制黑客攻击。它的缺点是算法比较复杂，实现起来比较麻烦。

1.3 集成 Windows 身份认证(Integrated)

集成认证又分为 NTLM 和 Kerberos2 种。NTLM认证方式需要把用户的 Windows 用户名和密码传送到服务端，服务端认证用户名和密码是否和服务器的此用户的信息一致。用户名用明码传送，但是密码是经过处理后派生出的一个 8 字节的密钥加密后传送。Kerberos 认证方式只把客户端访问 IIS 的认证票(Ticket)发送到 IIS 服务器，IIS 收到这个票据就能确定
客户端的身份，不需要传送用户的密码。需要kerberos 认证的用户一定是域用户。
虽然集成认证安全性比较高，但其只适用于Intranet 和 Windows 客户端，而且采用的用户信息是用户当前登录的 Windows 帐户信息，所以在
Internet 上实用性不高。

1.4 客户端证书认证(Client Certificate)

对于安全要求特别高的环境，可以使用客户端证书认证。客户端证书为 Web 应用程序提供了一种出色的身份认证机制。浏览器或其他客户端应用程序必须提供有效的证书才能被授予对应用程序的访问权，从而使客户端无需再提供用户名和密码。这就使得在创建由其他客户端应用程序访问的安全 Web服务时，客户端证书非常有用。
但是这种方式需要证书服务器的支持，而且比摘要认证复杂的多，而且十分消耗资源。虽然安全性很高，但对于一般程序，实用性不高。

2、自定义认证

自定义安全是采用自己定义的接口，来认证用户的身份。Web 服务公开认证接口，定义认证 API，客户端则按照 Web 服务的公开信息来实现认证。这种方式的优点是灵活，服务器端可以随意定义各种认证所需要的接口和算法，而不必拘泥于现有方法。
客户端必须首先学习所需要使用的 Web 服务的认证接口，才能使用服务。而且每个 Web 服务都有其自己的认证方式，导致通用性不高。

2.1 SOAP header 方式[2]

这种方式是用 SOAP 头来携带凭据信息。这种方式原理上是好的，而且 WS-Security 也是这么做的。它允许独立传送，允许加密密码或者直接传送 Hash凭据而不需要加密整个信息。但是缺点是客户端必须阅读 Web 服务的 API 文档才知道该怎么做，以手工的方式小心的以所要求的格式构建 SOAP 头，导致开发难度增大。而且，以 SOAP header 方式必须在每次Web 服务调用上都附加相应的用户凭据，同时服务器也得每次都进行认证，比较浪费资源。

2.2 登录方式

把 Web 服务看作是房子，把 Web 服务的认证看作是房子的门。房子允许很多人进入，但进入之前，必须要敲门。登录认证就是为了确保使用 Web 服务的人就是所宣称的那个人。这扇门需要用户提供凭据，然后他们会得到一个安全令牌以访问服务器。服务器返回的安全令牌可以有很多种方式，可以是保存在浏览器中的 Cookie，保存在服务器上的 Session Id 或者是一串字符。
登录方式是在使用一个 Web 服务之前，先用登录信息调用一个 Web 服务附属的登录方法，如果登录成功，则得到一个每次使用 Web 服务都要用的令牌。每次使用 Web 服务时，在 SOAP Header 或者参数中携带这个令牌。这种方式的优点是不用每次调用 Web 服务都需要传输凭据信息，而只需要认证一次。缺点则是对于每一个单独的 Web 服务，它需要
2 个来回(如果需要登出以便清理会话(Session)则需要 3 个来回)；而且 Web 服务需要实现会话模型，这比无会话模型困难。

3、采用现有工具包

3.1 Web Services Enhancements

WS-Security 是一种为了保证 Web 服务安全所定义的通信协议，其完整的实现了上文所提到 5 种安全性要求。微软的 Web Services Enhancements 工具包实现了 WS-Security 标准。但使用这种工具包，学习过程异常复杂，而且作为一个系统，即使只需要其中的一小块功能，也需要学习整个工具包的使用，导致实现过程漫长。而且，使用工具包的后果就是，会导致客户端越来越依赖工具包的黑箱实现，如果正常，一切都好；如果不正常，一个小问题就会破坏整个系统。这对于一般的对安全要求不高的 Web 服务来说，得不偿失。

3.2 Microsoft Windows Live ID

Microsoft Windows Live ID 认证是 Microsoft Windows Live 系统(以前称作 Passport)采用的一种认证方式，微软使用它提供了一种“单点登录”服务，它允许用户使用一个账户就可以登录多个 Web 网站，在系统内部，
这些凭据以 cookies 的形式存在。这种方式在ASP.NET 上容易简单实现，但缺点是通用性较差，是过于复杂，实现困难。而且，不具有开放性，用户信息保存在 Microsoft 的数据库中，不利于特定需求的扩展。

3.3 Liberty Alliance Project

Liberty 是一个商业联盟，成立于 2001 年 9 月，目标是建立一个统一的身份管理的开放标准。它也支持单点登录。其相对于 Microsoft Live ID的优点是其是开放的。

现有的Google Web服务
Google 的 Web 服务包括存取 Google 帐户信息的 Google Data APIs 和简单使用 Google 服务的Web 服务。Google Data APIs 允许用户在自己的程序中登录 Google 帐号。一旦登录，Google 返回一个令牌，每次用户存取帐户信息的时候都需要用到这个令牌。令牌在一段时间内有效。它根据客户端类别分为单用户桌面程序和多用户 Web 程序。单用户桌面程
序首先 Post 用户信息到 https://www.google.com/accounts/ClientLogin，如成功登录，得到令牌。以后每次对 API 的请求，HTTP 头上都要附加令
牌信息。格式为 Authorization: GoogleLoginauth=yourAuthToken。多用户 Web 程序可以采用AuthSub 和 OAuth 2 种方式进行认证。OAuth 是为
了保证安全 API 认证定义的一套开放标准，Google Data API 实现了这套标准。AuthSub 则是在 OAuth出现之前的认证方式。
如果不需要存取帐户信息，只是简单使用 Google服务的 Web 服务，例如 Google 地图，则使用序列号(API Key)方式，每个需要使用 Web 服务的客户端都申请一个序列号，每次使用时，需要携带序列号信息。