Home >> Blog >> 什麼是 OAuth？定義及其工作原理
什麼是 OAuth？定義及其工作原理
我們已經討論過洩露您的密碼以及您永遠不應該這樣做。當一個網站想要使用另一個網站的服務時——比如 Bitly 在你的 Twitter 流中發帖——而不是要求你分享你的密碼，他們應該使用一種稱為 OAuth 的協議。
了解程序、網站或應用程序如何驗證您作為用戶的身份很重要——他們是否擁有正確的權限？您是否授予他們某種方式來驗證您的身份並代表您訪問資料？OAuth 有助於簡化此過程：但即使使用自動化，也要始終了解個人或公司如何使用（或存儲）您的資料。
什麼是 OAuth？
OAuth 是一種開放標準的授權協議或框架，它為應用程序提供“安全指定訪問”的能力。例如，您可以告訴 Facebook ESPN.com 可以訪問您的個人資料或將更新發佈到您的時間線，而無需向 ESPN 提供您的 Facebook 密碼。這在很大程度上將風險降至最低：如果 ESPN 遭到破壞，您的 Facebook 密碼仍然安全。
OAuth 不共享密碼資料，而是使用授權令牌來證明消費者和服務提供者之間的身份。OAuth 是一種身份驗證協議，允許您批准一個應用程序代表您與另一個應用程序交互，而無需洩露您的密碼。
SAML 與 OAuth
SAML（安全斷言標記語言）是許多企業用於單點登錄 (SSO) 的另一種聯合身份驗證標準。SAML 使企業能夠監控誰有權訪問公司資源。
SAML 和 OAuth 之間有許多不同之處。SAML 使用 XML 傳遞消息，而 OAuth 使用 JSON。OAuth 提供更簡單的移動體驗，而 SAML 則面向企業安全。最後一點是一個關鍵的區別：OAuth 廣泛使用 API 調用，這就是為什麼移動應用程序、現代 Web 應用程序、遊戲控制台和物聯網 (IoT) 設備發現 OAuth 為用戶提供了更好的體驗。另一方面，SAML 會在瀏覽器中放置一個會話 cookie，允許用戶訪問某些網頁——這對於短暫的工作日非常有用，但在必須每天登錄恆溫器時就不那麼好了。
OAuth 示例
OAuth 的最簡單示例是一個網站說“嘿，你想用其他網站的登錄名登錄我們的網站嗎？” 在這種情況下，第一個網站——讓我們將那個網站稱為消費者——唯一想知道的是用戶是兩個網站上的同一用戶，並且已經成功登錄到服務提供商——即用戶所在的網站最初登錄，而不是消費者。
Facebook 應用程序是一個很好的 OAuth 用例示例。假設您在 Facebook 上使用一個應用程序，它要求您分享您的個人資料和圖片。在這種情況下，Facebook 是服務提供商：它擁有您的登錄資料和圖片。該應用程序是消費者，作為用戶，您希望使用該應用程序對您的圖片做一些事情。您專門授予此應用訪問您的圖片的權限，OAuth 在後台管理這些圖片。
您的智能家居設備 - 烤麵包機、恆溫器、安全系統等 - 可能使用某種登錄資料相互同步，並允許您從瀏覽器或客戶端設備管理它們。這些設備使用 OAuth 所謂的機密授權。這意味著他們會保留密鑰信息，因此您不必一遍又一遍地登錄。
OAuth 解釋
OAuth 是關於授權而不是身份驗證。授權是要求允許做某事。身份驗證是為了證明您是正確的人，因為您知道事情。OAuth 不在消費者和服務提供者之間傳遞身份驗證資料，而是充當某種授權令牌。
我在研究 OAuth 時看到的常見比喻是汽車的代客鑰匙。代客鑰匙允許代客啟動和移動汽車，但不允許他們進入行李箱或手套箱。
OAuth 令牌就像那個代客鑰匙。作為用戶，您可以從每個服務提供商處告訴消費者他們可以使用什麼以及不能使用什麼。您可以為每個消費者提供不同的代客鑰匙。他們從來沒有完整的密鑰或任何可以讓他們訪問完整密鑰的私人資料。
OAuth 的工作原理
OAuth 事務中有 3 個主要參與者：用戶、消費者和服務提供者。這個三人組被親切地視為 OAuth 三角戀。
在我們的示例中，Joe 是用戶，Bitly 是消費者，而 Twitter 是提供的服務，它控制 Joe 的安全資源（他的 Twitter 流）。Joe 希望 Bitly 能夠將縮短的連結發佈到他的信息流中。以下是它的工作原理：
第 1 步——用戶表現出意圖
- Joe（用戶）： “嘿，Bitly，我希望你能夠將連結直接發佈到我的 Twitter 流中。”
- Bitly（消費者）： “太好了！讓我去請求許可。”
第 2 步 – 消費者獲得許可
- Bitly： “我有一個用戶希望我在他的信息流中發帖。我可以有一個請求令牌嗎？”
- Twitter（服務提供商）： “當然。這是一個令牌和一個秘密。”
該秘密用於防止請求偽造。消費者使用密鑰對每個請求進行簽名，以便服務提供者可以驗證它實際上來自消費者應用程序。
第 3 步 – 用戶被重定向到服務提供商
- 比特利： “好的，喬。我正在將您發送到 Twitter，以便您批准。把這個令牌隨身攜帶。”
- 喬： “好！”
- Bitly 將 Joe 引導至 Twitter 以獲取授權>
這是可怕的部分。如果 Bitly 是超級陰暗的 Evil Co.，它可能會彈出一個看起來像 Twitter 的窗口，但實際上是對您的用戶名和密碼進行網絡釣魚。始終確保驗證您被定向到的 URL 實際上是服務提供商（在本例中為 Twitter）。
第 4 步 – 用戶授予權限
- Joe： “Twitter，我想授權 Bitly 給我的這個請求令牌。”
- Twitter： “好吧，只是為了確定，你想授權 Bitly 用你的 Twitter 賬戶做 X、Y 和 Z？”
- 喬： “是的！”
- Twitter： “好的，你可以回到 Bitly，告訴他們他們有權使用他們的請求令牌。”
Twitter 將請求令牌標記為“good-to-go”，因此當消費者請求訪問時，它將被接受（只要使用他們的共享密鑰簽名）。
第 5 步 – 消費者獲得訪問令牌
- Bitly： “Twitter，我可以用這個請求令牌交換訪問令牌嗎？”
- Bitly： “我想將此連結發佈到 Joe 的直播中。這是我的訪問令牌！”
- 推特： “完成！”
在我們的場景中，Joe 不必與 Bitly 分享他的 Twitter 憑據。他只是以安全的方式使用 OAuth 授權訪問。Joe 可以隨時登錄 Twitter 並查看他已授予的訪問權限並撤銷特定應用程序的令牌，而不會影響其他人。OAuth 還允許細粒度的權限級別。您可以授予 Bitly 在您的 Twitter 帳戶上發帖的權利，但將 LinkedIn 限制為只讀訪問。
OAuth 1.0 與 OAuth 2.0
OAuth 2.0 是對 OAuth 1.0 的完全重新設計，兩者不兼容。如果您今天創建一個新應用程序，請使用 OAuth 2.0。此博客僅適用於 OAuth 2.0，因為 OAuth 1.0 已被棄用。
OAuth 2.0 更快更容易實現。OAuth 1.0 使用複雜的加密要求，僅支持三個流，並且無法擴展。
另一方面，OAuth 2.0 有六個流程用於不同類型的應用程序和要求，並通過 HTTPS 啟用簽名機密。OAuth 令牌在 2.0 中不再需要在端點上加密，因為它們在傳輸過程中被加密。
其他資源
希望這是一本讓您熟悉 OAuth 的很好的入門書，因此下次您看到“使用 Twitter 登錄”或類似的委託身份驗證時，您將對正在發生的事情有一個很好的了解。
如果您想深入了解 OAuth 的機制，這裡有一些有用的連結：