nginx用戶認證配置（ Basic HTTP authentication）及認證原理和實現

配置

...

location /auth {
              # 相應的說明
              auth_basic "nginx basic http test for ttlsa.com";
              # 指定一個保存用戶名和密碼的文件
                auth_basic_user_file /usr/local/nginx/conf/htpasswd;
        }
...

htpasswd 文件生成:

賬號：ttlsa
密碼：123456

# printf "ttlsa:$(openssl passwd -crypt 123456)\n" >>conf/htpasswd
# cat conf/htpasswd
ttlsa:xyJkVhXGAZ8tM

原理

一． BASIC認證概述

        在HTTP協議進行通信的過程中，HTTP協議定義了基本認證過程以允許HTTP服務器對WEB瀏覽器進行用戶身份證的方法，當一個客戶端向HTTP服務器進行數據請求時，如果客戶端未被認證，則HTTP服務器將通過基本認證過程對客戶端的用戶名及密碼進行驗證，以決定用戶是否合法。
        客戶端在接收到HTTP服務器的身份認證要求後，會提示用戶輸入用戶名及密碼，然後將用戶名及密碼以BASE64加密，加密後的密文將附加於請求信息中。
        如當用戶名爲anjuta，密碼爲：123456時，客戶端將用戶名和密碼用“：”合併，並將合併後的字符串用BASE64加密爲密文，並於每次請求數據 時，將密文附加於請求頭（Request Header）中。
        HTTP服務器在每次收到請求包後，根據協議取得客戶端附加的用戶信息（BASE64加密的用戶名和密碼），解開請求包，對用戶名及密碼進行驗證，如果用 戶名及密碼正確，則根據客戶端請求，返回客戶端所需要的數據;否則，返回錯誤代碼或重新要求客戶端提供用戶名及密碼。

二． BASIC認證的過程

        1． 客戶端向服務器請求數據，請求的內容可能是一個網頁或者是一個其它的MIME類型，此時，假設客戶端尚未被驗證(即header中不帶正確的Authorization字段)，則客戶端提供如下請求至服務器:

Get /index.html HTTP/1.0
Host:www.google.com

        2． 服務器向客戶端發送驗證請求代碼401,服務器返回的數據大抵如下：

HTTP/1.0 401 Unauthorised
Server: SokEvo/1.0
WWW-Authenticate: Basic realm="google.com"
Content-Type: text/html
Content-Length: xxx

        3． 當符合http1.0或1.1規範的客戶端（如IE，FIREFOX）收到401返回值時，將自動彈出一個登錄窗口，要求用戶輸入用戶名和密碼。

        4． 用戶輸入用戶名和密碼後，將用戶名及密碼以BASE64加密方式加密，並將密文放入前一條請求信息中，則客戶端發送的第一條請求信息則變成如下內容(即在header中自動加入Authorization字段)：

Get /index.html HTTP/1.0
Host:www.google.com
Authorization: Basic xxxxxxxxxxxxxxxxxxxxxxxxxxxx

注：xxxx....表示加密後的用戶名及密碼。

        5． 服務器收到上述請求信息後，將Authorization字段後的用戶信息取出、解密，將解密後的用戶名及密碼與用戶數據庫進行比較驗證，如用戶名及密碼正確，服務器則根據請求，將所請求資源發送給客戶端：

三． BASIC認證的缺點

        HTTP基本認證的目標是提供簡單的用戶驗證功能，其認證過程簡單明瞭，適合於對安全性要求不高的系統或設備中，如大家所用路由器的配置頁面的認證，幾乎都採取了這種方式。
        其缺點是沒有靈活可靠的認證策略，如無法提供域（domain或realm）認證功能，另外，BASE64的加密強度非常低(直接把header中的Authorization字段拿去base64解密即可)，可以說僅 能防止sohu的搜索把它搜到了。
        當然，HTTP基本認證系統也可以與SSL或者Kerberos結合，實現安全性能較高（相對）的認證系統