什麼是認證和授權？如何設計一個許可權認證框架？

認證和授權是安全驗證中的兩個重要概念。認證是確認身份的過程，用於建立雙方之間的信任關係。只有在認證成功的情況下，雙方才可以進行後續的授權操作。授權則是在認證的基礎上，確定使用者或系統對資源的存取許可權。

在設計一個許可權認證框架時，可以考慮以下原則：資源、角色和主體。

資源：定義系統中的各種功能、資料或服務，例如頁面、API介面等。
角色：角色是對使用者或系統進行邏輯分組的一種方式。一個主體（使用者或系統）可以擁有一個或多個角色。每個角色可以被賦予不同的許可權，即可以存取哪些資源。
主體：主體是指進行認證和授權的實體，可以是使用者、系統或第三方應用程式。

在開發中，可以採用前端頁面按鈕許可權控制和後臺統一許可權控制的方式來確保安全存取。前端頁面按鈕許可權控制可以根據使用者角色或許可權設定顯示或隱藏頁面上的按鈕，以限制使用者的操作。後臺統一許可權控制可以通過中介軟體或攔截器來驗證使用者的認證資訊和許可權，確保使用者只能存取其被授權的資源。

Cookie和Session有什麼區別？如果沒有Cookie,Session還能進行身份驗證嗎？

Cookie和Session是用於進行身份驗證和狀態管理的兩種機制，在實現上有一些區別。

Cookie是由伺服器在響應中生成並儲存在使用者端的一種小型文字檔案。它可以包含一些狀態資訊，例如使用者身份標識、過期時間等。每次使用者端傳送請求時，會自動攜帶相應的Cookie資料，以便伺服器進行身份驗證和狀態管理。

Session是在伺服器端建立和管理的一種資料結構，用於儲存每個使用者的對談資訊。伺服器在接收到使用者端請求後，為每個對談生成一個唯一的session id，並將其傳送給使用者端儲存。使用者端在後續的請求中會攜帶該session id，伺服器根據id查詢對應的對談資訊，進行身份驗證和狀態管理。

由於Session的實現依賴於Cookie來傳遞session id，如果沒有Cookie，無法將對談資訊與請求進行關聯，從而無法進行有效的身份驗證。

在分散式部署的情況下，可以採取一些解決方案來處理Session的資訊儲存問題。常見的解決方案包括：

調整負載均衡策略：通過設定負載均衡器，將特定的使用者端請求固定傳送到某個伺服器上，以確保對談資訊的一致性。但是當該伺服器宕機或故障時，對談資訊將丟失。
Session複製：在叢集中的伺服器之間複製對談資訊，以保持一致性。但是在高並行環境下，如果複製過程未完成，就接收到了新的請求，會影響效能和一致性。
Session共用：使用第三方工具（如Redis）將對談資訊儲存在共用的快取中，每個伺服器都可以存取和更新該快取，以實現對談資訊在叢集中的共用和同步。

什麼是CSRF攻擊？如何防止？

CSRF（Cross-Site Request Forgery）攻擊是一種利用受害者在已經認證的狀態下執行非意願操作的攻擊方式。攻擊者通過誘使受害者存取惡意網站或點選惡意連結，來執行未經授權的操作，例如修改密碼、進行轉賬等，簡單來說就是，由於cookie是在瀏覽器共用的，所以一旦設定了cookie，那麼當你開啟另一個tab頁的時候，也會攜帶過去，那麼其他站點就可以使用cookie進行攻擊，具體如下：

比如：當你在瀏覽器中開啟銀行A的網頁併成功登入後，你想要進行轉賬操作。你使用GET請求存取了一個URL：https://www.banka.com/transfer?account=111&amount=1000。這個請求包含了轉賬所需的賬戶和金額資訊。

然而，同時你在另一個瀏覽器標籤中開啟了一個惡意網頁，這個網頁中包含了一個類似的URL：https://www.banka.com/transfer?account=111&amount=10000。由於你在之前登入銀行A的網頁時，瀏覽器會自動傳送之前的Cookie資訊，惡意網頁中的請求也會帶有相同的Cookie。

當你點選惡意網頁中的連結時，銀行A的伺服器會收到這個請求，並且由於存在有效的Cookie，會誤認為這是一個合法的請求，從而執行了轉賬操作，將10000的金額從你的賬戶中轉出。

為了防止CSRF攻擊，可以採取以下措施：

驗證請求來源：在伺服器端對請求進行驗證，確保請求來自合法的來源。可以通過檢查請求頭中的Referer欄位或使用自定義的Token進行驗證。
使用CSRF令牌（Token）：在每個表單或敏感操作的請求中，包含一個隨機生成的CSRF令牌。伺服器在接收到請求時，驗證令牌的有效性，確保請求是合法的。
限制敏感操作的許可權：確保只有授權的使用者才能進行敏感操作。這可以通過身份驗證和授權機制來實現。
使用驗證碼：在某些敏感操作中，要求使用者輸入驗證碼，以提高安全性。驗證碼可以有效防止自動化攻擊。
設定Cookie屬性：將Cookie設定為httponly屬性，防止JavaScript指令碼獲取和修改Cookie的值，減少攻擊者的可能性。
定期更新令牌：為了增加攻擊者破解令牌的難度，可以定期更新令牌，使其失效。

什麼是OAuth2.0協定？有哪幾種認證方式？什麼是JWT令牌？和普通令牌有什麼區別？

OAuth2.0是一種開放標準的授權協定，用於在第三方應用程式和服務之間進行安全的認證和授權。在OAuth2.0中，使用者可以通過授權伺服器將其身份驗證資訊與第三方應用程式共用。授權伺服器會頒發一個存取令牌，該令牌將用於向資源伺服器請求受保護資源。第三方應用程式使用存取令牌來獲取使用者授權的資源。

OAuth2.0的授權過程通常涉及以下幾個角色：

使用者：資源的所有者，可以授權第三方應用程式存取其資源。
第三方應用程式：需要存取使用者資源的應用程式。
授權伺服器：負責驗證使用者身份並頒發存取令牌。
資源伺服器：儲存和提供受保護資源的伺服器。

OAuth2.0有以下幾種認證方式：

授權碼模式（Authorization Code Grant）：在這種模式下，使用者通過瀏覽器將自己的憑證（例如使用者名稱和密碼）提供給認證伺服器，然後獲取一個授權碼。授權碼隨後被用於交換存取令牌和重新整理令牌。

簡化模式（Implicit Grant）：這種模式下，使用者在瀏覽器中直接發起認證請求，認證伺服器將令牌直接返回給瀏覽器，然後瀏覽器將令牌傳遞給第三方應用程式。第三方應用可以直接在前端頁面獲取存取令牌，而無需通過後臺進行回撥。

密碼模式（Resource Owner Password Credentials Grant）：在這種模式下，使用者將自己的憑證直接提供給第三方應用程式，然後第三方應用程式使用這些憑證直接向認證伺服器請求令牌。

使用者端模式（Client Credentials Grant）：這種模式下，第三方應用程式直接使用自己的憑證向認證伺服器請求令牌，而沒有使用者的參與。

JWT（JSON Web Token）令牌是一種輕量級的認證和授權機制，它是由一串經過Base64編碼的JSON資料組成的令牌。JWT令牌包含了使用者的身份資訊和許可權資訊，並且被數位簽章以確保其完整性和真實性。

在一般情況下，獲取的令牌token並沒有實際作用，它只是用來建立信任，使得第三方應用可以呼叫授權平臺的介面。然而，獲取使用者資訊介面通常成為一個瓶頸，因為第三方平臺需要獲取並儲存授權平臺的使用者基本資訊。與普通令牌不同，JWT令牌是通過加密生成的一系列資訊，第三方應用可以直接通過JWT令牌獲取使用者相關資訊，無需呼叫使用者基本資訊介面，從而減輕了使用者資訊介面的壓力。

什麼是SSO？與OAuth2.0有什麼關係

SSO（Single Sign-On）是一種身份驗證和授權機制，它允許使用者在一次登入後存取多個相關應用系統而無需再次輸入憑證。SSO的目標是提供便捷的使用者體驗，減少使用者的登入負擔。

OAuth2.0是一種授權框架，它允許使用者授權第三方應用存取其受保護的資源，而無需將使用者名稱和密碼直接提供給第三方應用。OAuth2.0的主要目標是授權和保護使用者的資源，並確保使用者可以控制對其資源的存取許可權。

雖然SSO和OAuth2.0有相似的目標，都是為了提供使用者便利和安全的身份驗證和授權機制，但它們的實現和應用場景有所不同。SSO通常用於組織內部的應用系統，而OAuth2.0更多地用於第三方應用和開放平臺之間的授權。雖然OAuth2.0也可以用於實現SSO，但通常需要一個獨立的認證授權伺服器來處理認證和授權請求鏈路，以驗證使用者的登入資訊。

簡而言之，SSO強調的是一次登入，多個應用系統使用；而OAuth2.0強調的是一次註冊，多個應用系統授權存取。儘管OAuth2.0也可以用於實現SSO，但在實際應用中更常見的是將其用於第三方授權的場景。

如何設計一個開放授權平臺？

以下是設計一個開放授權平臺的一些基本考慮點，具體的實現和架構會根據具體的需求和技術選型而有所不同。

使用者註冊和登入：提供使用者註冊和登入功能，確保使用者可以存取他們的應用和授權資訊。
應用註冊和管理：允許開發者註冊和管理他們的應用，包括應用名稱、回撥URL、應用圖示等資訊。
授權流程：定義授權流程，包括使用者授權請求、使用者登入確認、應用授權確認等步驟。確保所有授權請求都經過使用者的明確同意。
安全性保障：採用合適的加密演演算法和安全策略，確保使用者的敏感資訊和授權令牌的安全性。
監控和紀錄檔：監控平臺的執行狀態和授權活動，記錄紀錄檔，以便及時發現和處理異常情況。
開發者檔案和支援：提供清晰的開發者檔案和技術支援，幫助開發者正確使用授權平臺和接入流程。

總結

總的來說，認證和授權是構建安全系統的重要組成部分。通過合理設計許可權認證框架，我們可以確保只有合法使用者能夠存取和執行相應的操作。在處理使用者身份認證時，Cookie和Session是常用的機制，但在分散式部署時需要注意Session的儲存和共用問題。此外，為了防止CSRF攻擊，我們可以採取一些措施，如使用CSRF令牌和驗證請求來源。最後，設計開放授權平臺時，需要考慮安全性、靈活性和易用性等因素。

最後，希望這篇安全驗證的內容對你的面試和工作有所幫助！同時，也歡迎你瀏覽整個專欄的其他內容，以獲取更多有用的資訊。