目前比較成熟的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 服務的客戶端都申請一個序列號，每次使用時，需要攜帶序列號信息。
