BuzzFeed是如何基於OAuth實現集中的單點登入的？
BuzzFeed過去一直使用ofollow,noindex" target="_blank">oauth2_proxy ，這個解決方案很可靠，但它缺乏集中的方式讓他們的使用者登入，這為不斷髮展的平臺帶來了一些挑戰。所以他們做了任何優秀工程師都會做的事情：在開源中尋找其他現有的、經過測試的解決方案。然而，雖然他們從同行那裡聽說這是一個常見的問題，但從未找到符合他們規格的東西。因此，他們創造了sso 這個開源專案，共享出他們的集中式認證代理，也就是單點登入模組，下面是原文大意提煉：
作為運營商，管理auth代理服務的激增證明是困難的。關鍵安全修復需要超過70個補丁和部署，而不僅僅是一個。審計和控制跨服務的訪問也是一項持續的挑戰。為了解決這個問題，我們需要找到一種集中訪問和管理的方法。這也將為終端使用者創造更愉快的體驗，終端使用者在當前狀態下需要單獨登入到每個服務。在理想情況下，使用者可以執行單點登入，並在配置的時間跨度內訪問所有授權服務。
我們對這些難點的解決方案是sso ，是對中央認證服務（ [url=https://en.wikipedia.org/wiki/Central_Authentication_Service]CAS）[/url]協議的OAu th2友好改編。允許我們用單一的集中式系統取代每項服務的登入，提供無縫，安全的單點登入體驗，輕鬆稽核，豐富的測量方式和無痛的開發人員體驗。
我們的實現是由兩個服務，sso-auth並且sso-proxy，協作執行兩個巢狀的認證流程和代理請求。
SSO-AUTH
sso-auth充當中央認證服務，引導使用者通過與第三方提供商（例如，Google）的認證流程。它使用第三方提供商的組API（例如，Google網上論壇）為授權提供簡單的管理使用者體驗。
SSO-PROXY
sso-proxy類似sso-auth提供的OAuth流程，但sso-auth作為它的身份認證提供程式。在完成流程後，它將請求代理回到它的上游。此外，它簽署請求，為上游提供認證機制 ，認證來自sso-proxy的 請求。
無論sso-auth和sso-proxy都長時間可以加密儲存使用者會話資訊在Cookies中，但sso-proxy透明地重新驗證使用者的會話，sso-auth是有一個短的、可配置的時間間隔，從而保證認證和授權更改能夠快速傳播。
認證流程：
驗證許可權的流程：
當終端使用者訪問內部資源時，例如cms.example.com：
-
sso-proxy 首先嚐試讓通過認證已經儲存會話到cookie的客戶端來認證使用者。
- 如果cookie不存在或已達到重新整理截止日期，sso-proxy將和sso-auth一起開始一個認證流程，將使用者重定向到auth.example.com開始這個新流程.
- sso-auth 檢查其會話cookie以檢視它是否存在以及它是否仍然有效。[list=1]
- 如果cookie不存在或無效，它會將使用者重定向到第三方提供程式進行身份認證，並將會話資訊儲存在會話cookie中。
- 如果流程成功，sso-proxy則從sso-auth認證程式碼接收回調並將其交換為訪問令牌，然後執行對伺服器的API呼叫以檢索有關使用者的授權資訊。
如果它是有效的cookie，則該請求將被代理到上游。
其他備選方案
我們之前考慮了幾種替代方法。比如像Keycloak ，但我們最終覺得從現有的分散式oauth2_proxy例項叢集遷移到集中式集合更容易。我們也不相信有必要引入資料庫來滿足我們的要求，Keycloak依賴於資料庫。無狀態和雲原生系統更易於部署。此外，oauth2_proxy 使得基於OAuth的解決方案比SAML更加自然。