前言

在 Day 2 我們提到：一個系統要先確認「你是誰」（Authentication），再決定「你能做什麼」（Authorization）。在了解這個觀念後，我們就要來介紹最初的程式是如何實作Authorization的。

在開始前，希望大家會先有Http有一定程式的了解，知道Get、Post，以及Http在夾帶資料的時候所需要攜帶的Header、body等等的觀念，會更容易理解以下的內容。如果沒有，會建議大家先去網路上看過，理解相關資料之後再來看唷！

那麼，最古老、最簡單的「確認你是誰」的方式是什麼呢？

就是 Basic Authentication（基本認證）。

它的設計理念很直接：每次請求都把帳號密碼一起帶上來。

Basic Authentication 的運作原理

1. 使用者發送 HTTP 請求時，會在 Header 帶上 Authorization 欄位：

   Authorization: Basic <帳號密碼的Base64編碼>
   

2. 伺服器收到後，會把 <Base64編碼> 解開，得到：

   username:password
   

3. 伺服器驗證帳密是否正確 → 正確就放行，錯誤就回 401 Unauthorized。

舉例說明

假設帳號是 user，密碼是 1234，那麼：

1. 組合成字串：

   user:1234
   

2. 轉成 Base64：

   dXNlcjoxMjM0
   

3. 放進 HTTP Header：

   Authorization: Basic dXNlcjoxMjM0
   

伺服器只要解碼，就能知道這是誰。

這個Basic Authorization有以下優缺點：

優點

1. 簡單
   • 實作容易，不需要額外的機制。
   • 幾乎所有 HTTP Client（Postman、curl、瀏覽器）都支援。
2. 歷史悠久
   • 很多早期的 API、伺服器管理工具（例如早期的 Tomcat、Nginx 設定）都用 Basic Auth。
   • 直到現在還能看到它的影子，特別是在一些內部系統或測試環境。

缺點

1. 帳密每次都會傳送

   • 意味著駭客只要攔截一次封包，就能拿到帳號密碼。
   • Base64 不是加密，只是編碼，所以非常容易解碼。這個我們可以從任意的網站就能看到，例如我們登入一個Base64解碼文本，把剛剛的密碼貼上，就會直接得到我們的帳號密碼
     

2. 沒有 Session 或 Token 概念

   • 使用者每次請求都要重新帶帳密，伺服器也要每次驗證，效率低。每次登入的過程中如果有任何攔截，只要攔截到一次，駭客就可以把你的資料整鍋端走。

3. 安全性不足

   • 無法支援登出（因為伺服器根本不記錄狀態）。
   • 一旦帳密外洩，整個系統就完全暴露。

因為以上的缺點，在現代專案其實都已經不再使用 Basic Auth，除非是在以下情況：

• 內部測試環境
• 單次短期使用的 API 測試
• 搭配 HTTPS 確保傳輸加密

這類最初始的加密就像我們的一天的口令一樣，實作Basic Auth 後，每次進門都要大聲報出「趙飛燕，吃香蕉，我房間」。哨兵每次都會聽到 → 確認沒錯 → 放行。

但是當有人在旁邊偷聽，你的口令就曝光了。而且每次都要重複喊，沒有「記憶」功能。

當然哨兵可以一個一個處理，但是如果是像Facebook,Dcard等等大公司，每秒都有成千上萬的請求，每個請求都要處理一次，每次都要帶密碼，任何人只要隨便撈到一次，就等於成功竊取到一個個資，所以現代已經很少在使用。

總結

• Basic Authentication 是最古老、最簡單的認證方式。
• 它的核心精神就是：每次請求都把帳密附上來。
• 雖然簡單，但因為安全性不足，現代系統幾乎不會單獨使用。

學習它仍然很重要，因為它是後續 Token、Session、JWT 的基礎概念來源。

今天的教學就到這裡了，明天我們會實際用 Spring Boot Security 來做一個 Basic Authentication 的範例，並用 Postman 測試。

到時候你就能清楚看到：

• 怎麼設定 Basic Auth
• 請求 API 時，如何自動帶上 Authorization Header

今天就分享到這裡，明天就是真正的實際使用程式碼了，我自己也手癢了很多天了，那就讓我們明天見囉～