Day 8 | 🚪 門禁與權限之鑰：深入解析 Authentication & Authorization

嗨，各位鐵人夥伴！ 👋

這是一篇專為新手設計的入門指南。如果您是經驗豐富的開發者，可以考慮跳過，或將它分享給需要引導的新人，相信能有效節省您寶貴的指導時間！ 😉

本文將以最淺顯易懂的方式，帶您一次搞懂以下核心概念：

• Authentication & Authorization (認證與授權)
• 常見的系統登入機制
• SSO (單一登入)
• AD (Active Directory)
• Native Account (原生帳號)
• OAuth 2.0
• JWT (JSON Web Token)
• RBAC (角色權限控制)

🤔 Authentication vs. Authorization：你是誰？你能做什麼？

首先，我們必須釐清 Authentication (認證) 與 Authorization (授權) 這兩個概念的關鍵差異。

• Authentication (認證) 🛡️
  簡單來說，就是**「確認你是誰」**。這是使用者進入系統的第一道門檻，也就是我們熟知的「登入」流程。系統透過驗證你的身份憑證（如帳號密碼），來判斷你是否為合法使用者。

• Authorization (授權) 🔑
  當你通過認證並登入系統後，「決定你能做什麼」 的就是授權機制。它定義了不同使用者擁有哪些權限，可以存取哪些資源或執行哪些操作。

這兩者是建構任何安全系統的基石，請務必清楚它們的區別。至於為什麼要做認證與權限控管？除了這是資安的基本要求外，若沒有妥善設計，在稽核時可是會被電到飛起來的！

🧐 常見的 Authentication (認證) 機制

「認證不就是比對帳號密碼嗎？」話是沒錯，但實務上根據不同的應用場景，有許多常見的術語和整合方式。

🏢 企業內部系統 (對內)

在企業環境中，通常會有多個內部系統。如果每套系統都需要一組獨立的帳密，對使用者來說將會是場災難。因此，常會聽到串接 SSO 或 AD/LDAP 的需求，目的就是讓使用者不必為您的系統多記一組密碼。

• SSO (Single Sign-On) ✨
  單一登入機制。使用者一天中可能只需要登入一次（例如，登入公司電腦或內部入口網站 Portal）。當他們要使用您的系統時，只需點擊網址，連登入畫面的帳密都不用輸入，系統之間會透過背後的信任機制自動完成認證。

• AD/LDAP 🖥️
  AD 是 Windows Active Directory 的簡稱，而 LDAP 是串接它的主要協定。當系統串接 AD 時，使用者在登入您的系統時，需要輸入他們在 AD 中的帳號密碼。因為這組帳密通常就是他們的電腦登入密碼，所以使用者幾乎不會忘記，也達成了統一管理的目的。最後補充 : 有些企業喜歡叫 Window 那套簡稱 NT，這有歷史因素只是補充一下

• Native (原生帳密) 📝
  這不是一個標準術語，但業界常用它來表達系統本身獨立建置了一套帳號密碼機制。也就是說，使用者必須在您的系統上註冊一組專屬的帳號密碼才能登入。這邊提醒一個常識中的常識：密碼絕對不可以用明文儲存在資料庫！ 請務必使用不可逆的加密演算法（如 bcrypt）進行儲存。

🌐 面向外部客戶的系統 (對外)

當系統的使用者是外部客戶時，通常會提供更便利的登入選項。

• OAuth 2.0 🤝
  這是一個授權框架，聽起來很專業，但您肯定每天都在用。最常見的例子就是**「使用 Google / Facebook / Apple ID 登入」**。它允許使用者授權第三方應用程式存取他們在特定服務上的部分資訊，而無需將自己的帳密直接提供給該應用程式。其架構較為複雜，但極大提升了使用者體驗。

🚀 Authentication 的後續追蹤手段

使用者登入只發生在請求 (Http Request) 的那一瞬間。但 HTTP 協定本身是無狀態的 (Stateless)，這意味著後續的每個操作，系統都必須重新確認使用者是誰、是否仍處於登入狀態。總不能讓使用者每點一個按鈕就重新輸入一次密碼吧？

為了解決這個問題，主要有兩種常見的技術手段：

• Session-Cookie 🍪
  使用者成功登入後，伺服器 (Server) 會建立一個 Session 物件來儲存用戶的登入狀態，並產生一組獨一無二的 Session ID。伺服器會透過 HTTP Response，將這組 Session ID 存放在使用者的瀏覽器 Cookie 中。之後的每次請求，瀏覽器都會自動帶上這個 Cookie，伺服器就能藉由 Session ID 找到對應的 Session 物件，從而判斷使用者的登入狀態。

• JWT (JSON Web Token) 🎟️
  JWT 是目前前後端分離架構下的主流方案。簡單來說，使用者成功登入後，伺服器會生成一個經過加密、不可偽造的 Token (令牌) 並回傳給前端。前端通常會將此 Token 儲存起來（例如，在 localStorage 或 HttpOnly Cookie 中）。之後的每次請求，前端都需要在 Header 中附上這個 Token。伺服器收到請求後，會先驗證 Token 的合法性，確認無誤後才處理該請求。與 Session 的主要差異在於，JWT 的資訊是儲存在客戶端，伺服器本身不需儲存任何狀態，這對於系統的水平擴展 (Horizontal Scaling) 非常有利。

⚖️ Authorization 的主流選擇：RBAC

Authorization (授權) 處理的是使用者登入後「可以做什麼」的問題。授權的實作方式有很多種，但最廣泛應用的模型之一就是 RBAC。

• RBAC (Role-Based Access Control) 👑
  基於角色的權限控制。聽起來很學術，但核心思想非常簡單：「不要直接對使用者分配權限，而是對角色 (Role) 分配權限，再將角色賦予使用者。」

  舉個例子，假設我們在開發一個行銷活動管理系統，可以定義以下三種角色：

  1. Campaign_Viewer (活動檢視者)

     • read_campaign: 允許讀取活動資訊

  2. Campaign_Creator (活動建立者)

     • read_campaign: 允許讀取活動資訊
     • create_campaign: 允許建立新活動

  3. Campaign_Admin (活動管理員)

     • read_campaign: 允許讀取活動資訊
     • create_campaign: 允許建立新活動
     • approve_campaign: 允許審核並發布活動

  透過這樣的設計，當有新成員加入團隊時，我們只需要根據他的職責，賦予他一個或多個對應的角色，他就自動擁有了該角色下的所有權限。這遠比一個一個去勾選單獨權限要高效且不易出錯。

✅ 總結

今天我們深入探討了系統安全的兩大基石：Authentication 與 Authorization。掌握它們不僅是為了應付資安稽核，更是打造一個穩健、可信賴系統的基礎。

• Authentication (認證) 問的是**「你是誰？」**。我們了解了企業內部常用的 SSO、AD/LDAP，以及系統獨立的 Native 原生帳密機制。對於外部使用者，OAuth 2.0 則提供了無縫接軌的社群登入體驗。同時，我們也探討了 Session-Cookie 與 JWT 這兩種在登入後持續追蹤使用者狀態的關鍵技術。

• Authorization (授權) 問的是**「你能做什麼？」**。我們聚焦在 RBAC (基於角色的權限控制) 這個強大又直觀的模型。透過將權限賦予「角色」而非直接賦予「使用者」，我們可以大幅簡化權限管理的複雜度，讓系統的維護與擴展變得更加輕鬆。

希望今天的內容能幫助您建立清晰的觀念。一個好的權限系統，是所有複雜應用的起點！