由於或其他明文網絡協議工具手動地測試Web服務器。這是壹個麻煩的過程，但是網絡上傳輸的內容是人可讀的，以便進行診斷。
缺點雖然基本認證非常容易實現，但該方案創建在以下的假設的基礎上，即：客戶端和服務器主機之間的連接是安全可信的。特別是，如果沒有使用SSL/TLS這樣的傳輸層安全的協議，那麽以明文傳輸的密鑰和口令很容易被攔截。該方案也同樣沒有對服務器返回的信息提供保護。 現存的瀏覽器保存認證信息直到標簽頁或瀏覽器被關閉，或者用戶清除歷史記錄。HTTP沒有為服務器提供壹種方法指示客戶端丟棄這些被緩存的密鑰。這意味著服務器端在用戶不關閉瀏覽器的情況下，並沒有壹種有效的方法來讓用戶註銷。
優缺點
session-cookie的缺點
（1）認證方式局限於在瀏覽器中使用， cookie 是瀏覽器端的機制，如果在app端就無法使用 cookie 。
（2）為了滿足全局壹致性，我們最好把 session 存儲在 redis 中做持久化，而在分布式環境下，我們可能需要在每個服務器上都備份，占用了大量的存儲空間。
（3）在不是 Https 協議下使用 cookie ，容易受到 CSRF 跨站點請求偽造攻擊。
token 是壹個令牌，當瀏覽器第壹次訪問服務端時會簽發壹張令牌，之後瀏覽器每次攜帶這張令牌訪問服務端就會認證該令牌是否有效，只要服務端可以解密該令牌，就說明請求是合法的。壹般 token 由用戶信息、時間戳和由 hash 算法加密的簽名構成。
優點 ：
（1） token 認證不局限於 cookie ，這樣就使得這種認證方式可以支持多種客戶端，而不僅是瀏覽器。且不受同源策略的影響。
（2）不使用 cookie 就可以規避CSRF攻擊。
（3） token 不需要存儲， token 中已包含了用戶信息，服務器端變成無狀態，服務器端只需要根據定義的規則校驗這個 token 是否合法就行。這也使得 token 的可擴展性更強。
缺點 ：
（1）加密解密消耗使得 token 認證比 session-cookie 更消耗性能。
（2） token 比 sessionId 大，更占帶寬。
由於app沒有瀏覽器無法存儲cookie，故出現了OAuth，且允許用戶授權第三方網站訪問他們存儲在另外的服務提供者上的信息，與以往的授權方式不同之處是OAuth的授權不會使第三方觸及到用戶的帳號信息（如用戶名與密碼），即第三方無需使用用戶的用戶名與密碼就可以申請獲得該用戶資源的授權，因此OAuth是安全的。