筆記。 翻譯。：Okta 的這篇精彩文章解釋了 OAuth 和 OIDC (OpenID Connect) 如何以簡單明了的方式工作。 這些知識對開發人員、系統管理員，甚至是流行網絡應用程序的“普通用戶”都有用，這些應用程序很可能還與其他服務交換機密數據。
在互聯網的石器時代，服務之間共享信息很容易。 您只需將您的登錄名和密碼從一項服務提供給另一項服務，這樣他就可以進入您的帳戶並收到他需要的任何信息。
“給我你的銀行賬戶。” “我們保證只要有密碼和錢，一切都會好起來的。 老實說，老實說！” *嘻嘻*
恐怖！ 任何人都不應該要求用戶共享用戶名和密碼， 證書, 與另一項服務。 無法保證此服務背後的組織會保護數據安全並且不會收集不必要的個人信息。 這聽起來很瘋狂，但一些應用程序仍在使用這種做法！
今天有一個單一的標準，允許一項服務安全地使用另一項服務的數據。 不幸的是，這些標準使用了很多行話和術語，這使他們的理解變得複雜。 這個材料的目的是用簡單的插圖來解釋它們是如何工作的（你覺得我的畫像孩子們的塗抹嗎？哦好吧！）。
順便說一句，本指南也有視頻格式：
女士們，先生們，歡迎：OAuth 2.0
是一種安全標準，允許一個應用程序獲得訪問另一個應用程序中的信息的權限。 頒發許可證的步驟順序 [允許] （或者 同意 [同意]) 經常打電話 授權 [授權] 甚至 委託授權 【委託授權】. 使用此標準，您允許應用程序代表您讀取數據或使用另一個應用程序的功能，而無需提供您的密碼。 班級！
例如，假設您發現了一個名為“每日不幸雙關語”的網站 [今天可怕的雙關語] 並決定在上面註冊，以便在手機上以短信的形式接收每日雙關語。 您真的很喜歡這個網站，並決定與所有朋友分享。 畢竟，每個人都喜歡令人毛骨悚然的雙關語，對吧？
“今天不幸的雙關語：聽說過失去左半身的人嗎？ 現在他永遠是對的！” （近似翻譯，因為原文有自己的雙關語 - 近似翻譯。）
很明顯，不能給聯繫人列表中的每個人寫信。 而且，如果你有一點像我，那麼你會竭盡全力避免不必要的工作。 幸運的是，Terrible Pun of the Day 可以自己邀請所有的朋友！ 為此，您只需要打開對聯繫人電子郵件的訪問權限——網站本身會向他們發送邀請（OAuth 規則）！
“每個人都喜歡雙關語！ - 已經登錄？ “您願意允許 Terrible Pun of the Day 網站訪問您的聯繫人列表嗎？ - 謝謝你！ 從現在開始，我們將每天向您認識的每個人發送提醒，直到時間的盡頭！ 你是最好的朋友！”
- 選擇您的電子郵件服務。
- 如有必要，請轉到郵件站點並登錄您的帳戶。
- 授予 Terrible Pun of the Day 訪問您的聯繫人的權限。
- 返回 Terrible Pun of the Day 網站。
如果您改變主意，使用 OAuth 的應用程序還提供了一種撤銷訪問權限的方法。 一旦您決定不再希望與 Terrible Pun of the Day 共享聯繫人，您可以轉到郵件站點並將該雙關語站點從授權應用程序列表中刪除。
OAuth 流程
我們剛剛經歷了通常所說的 流動 [流動] OAuth。 在我們的示例中，此流程由可見步驟和幾個不可見步驟組成，其中兩個服務就安全信息交換達成一致。 前面的 Terrible Pun of the Day 示例使用了最常見的 OAuth 2.0 流程，稱為“授權代碼”流程。 【“授權碼”流程】.
在深入了解 OAuth 的工作原理之前，讓我們先談談一些術語的含義：
- 資源所有者:
是你！ 您擁有您的憑據、您的數據，並控制可能在您的帳戶上執行的所有活動。 - 客戶端:
一個應用程序（例如 Terrible Pun of the Day 服務）想要代表 資源所有者'一個。 - 授權服務器:
知道的應用程序 資源所有者'a 並且你在其中 資源所有者'一個已經有一個帳戶。 - 資源服務器:
應用程序編程接口 (API) 或服務 客戶端 想代用 資源所有者'一個。 - 重定向 URI:
那個鏈接 授權服務器 將重定向 資源所有者'並在授予許可後 客戶端'在。 它有時被稱為“回調 URL”。 - 響應類型:
預期收到的信息類型 客戶端. 最常見的 響應類型'ohm 是代碼，即 客戶端 期望收到 授權碼. - 範圍:
這是所需權限的詳細說明 客戶端'y，例如訪問數據或執行某些操作。 - 同意聲明:
授權服務器 貝雷帽 領域要求 客戶端'om，然後問 資源所有者'a, 他準備好提供 客戶端'有適當的權限。 - 客戶ID:
此 ID 用於識別 客戶端'a on 授權服務器'e. - 客戶機密:
這是只有自己知道的密碼 客戶端'你和 授權服務器'在。 它允許他們私下共享信息。 - 授權碼:
有效期短的臨時代碼， 客戶端 提供 授權服務器'y 作為交換 訪問令牌. - 訪問令牌:
客戶端將用來與之通信的密鑰 資源服務器嗯。 一種徽章或鑰匙卡，提供 客戶端'有權請求數據或執行操作 資源服務器'代表你。
注意: 有時授權服務器和資源服務器是同一台服務器。 但是，在某些情況下，這些可能是不同的服務器，即使它們不屬於同一組織。 例如，授權服務器可能是資源服務器信任的第三方服務。
現在我們已經介紹了 OAuth 2.0 的核心概念，讓我們回到我們的例子，仔細看看 OAuth 流程中發生了什麼。
- 你， 資源所有者, 你想提供 Terrible Pun of the Day 服務 (客戶端y) 訪問您的聯繫人，以便他們可以向您的所有朋友發送邀請。
- 客戶端 將瀏覽器重定向到頁面 授權服務器'a 並包含在查詢中 客戶ID, 重定向 URI, 響應類型 和一個或多個 領域 （權限）它需要。
- 授權服務器 驗證您，必要時詢問用戶名和密碼。
- 授權服務器 顯示一個表單 同意聲明 （確認）以及所有的列表 領域要求 客戶端嗯。 你同意或拒絕。
- 授權服務器 將您重定向到該站點 客戶端'a, 使用 重定向 URI 與...一起 授權碼 （授權碼）。
- 客戶端 直接與 授權服務器'ohm（繞過瀏覽器 資源所有者'a) 並安全發送 客戶ID, 客戶機密 и 授權碼.
- 授權服務器 檢查數據並響應 訪問令牌'om（訪問令牌）。
- 現在 客戶端 可以使用 訪問令牌 發送請求到 資源服務器 獲取聯繫人列表。
客戶端 ID 和密碼
早在您允許 Terrible Pun of the Day 訪問您的聯繫人之前，客戶端和授權服務器就已經建立了工作關係。 授權服務器生成客戶端 ID 和客戶端密鑰（有時稱為 應用程序ID и 應用機密) 並將它們發送給客戶端，以便在 OAuth 中進行進一步的交互。
“- 你好！ 我想和你一起工作！ - 當然，沒問題！ 這是您的客戶 ID 和機密！”
該名稱暗示客戶端密鑰必須保密，以便只有客戶端和授權服務器知道它。 畢竟，正是在他的幫助下，Authorization Server 才確認了 Client 的真實性。
但這還不是全部……歡迎 OpenID Connect！
OAuth 2.0 專為 授權 - 提供從一個應用程序到另一個應用程序的數據和功能訪問。 (OIDC) 是 OAuth 2.0 之上的一個薄層，它添加了登錄帳戶的用戶的登錄和個人資料詳細信息。 登錄會話的組織通常稱為 驗證 [驗證]，以及有關登錄系統的用戶的信息（即關於 資源所有者'e), — 個人資料 [身份]. 如果授權服務器支持 OIDC，它有時被稱為 個人資料提供者 [身份提供者]因為它提供 客戶端'有關於的信息 資源所有者'e.
OpenID Connect 允許您實現可以在多個應用程序中使用單個登錄的場景 - 這種方法也稱為 單點登錄 （單點登錄）。 例如，應用程序可能支持與 Facebook 或 Twitter 等社交網絡的 SSO 集成，允許用戶使用他們已經擁有並喜歡使用的帳戶。
OpenID Connect 的流程（flow）看起來和 OAuth 的情況一樣。 唯一不同的是，在初級請求中，使用的具體範圍是 openid， - A 客戶端 最終變得像 訪問令牌和 身份證.
就像在 OAuth 流程中一樣， 訪問令牌 在 OpenID Connect 中，這是一些不清楚的值 客戶端'在。 從角度來看 客戶端'一個 訪問令牌 表示隨每個請求一起傳遞給的字符串 資源服務器'y，它確定令牌是否有效。 身份證 代表完全不同的東西。
ID Token 是一個 JWT
身份證 是一種特殊格式的字符串，稱為 JSON Web Token 或 JWT （有時 JWT 令牌發音像“jots”）. 對於外部觀察者來說，JWT 可能看起來像是難以理解的胡言亂語，但是 客戶端 可以從JWT中提取各種信息，比如ID、用戶名、登錄時間、有效期 身份證'a，存在干擾 JWT 的企圖。 裡面的數據 身份證'一個被稱為 應用程序 [索賠].
對於 OIDC，還有一種標準方法 客戶端 可能會要求提供有關個人的其他信息 [身份] 從 授權服務器'a，例如，電子郵件地址使用 訪問令牌.
了解有關 OAuth 和 OIDC 的更多信息
因此，我們簡要回顧了 OAuth 和 OIDC 的工作原理。 準備好深入挖掘了嗎？ 以下是可幫助您了解有關 OAuth 2.0 和 OpenID Connect 的更多信息的其他資源：
一如既往，請隨時發表評論。 要了解我們的最新消息，請訂閱 и 面向開發人員的 Okta！
譯者PS
另請閱讀我們的博客：
- «“;
- «“;
- «“;
- «“。
來源： www.habr.com