有哪些新聞媒體提供Open API？
OAuth 2.0?是一種安全標準，您可以授予一個應用程序訪問另一個應用程序中的數據的權限。授予權限或同意的步驟通常稱為授權，甚至稱為委托授權。您授權一個應用程序訪問您的數據，或代表您使用另一個應用程序中的功能，而無需向它們提供您的密碼。甜！
舉個例子，假設你發現了一個名為“每日糟糕雙關語”的網站，并注冊了一個賬戶，讓它每天向你的手機發送一條糟糕的雙關語笑話作為短信。你非常喜歡它，想要與你曾在網上遇到過的每一個人分享這個網站。誰不想每天都讀一個糟糕的雙關語呢，對吧？
而且，如果你像我一樣，你會想盡一切辦法避免任何像是工作的事情。幸運的是，“每日糟糕雙關語”有一個邀請朋友的功能！您可以授予“Terrible Pun of the Day”對您的電子郵件聯系人的訪問權限并為您發送電子郵件！OAuth 取勝！
如果您改變主意，使用 OAuth 授予訪問權限的應用程序也提供了一種撤銷訪問權限的方法。如果您稍后決定不再共享您的聯系人，您可以轉到您的電子郵件提供商并刪除“Terrible Pun of the Day”作為授權應用程序。
您剛剛逐步完成了通常所說的 OAuth 流。此示例中的 OAuth 流由授予同意的可見步驟以及一些不可見的步驟組成，其中兩項服務就交換信息的安全方式達成一致。前面的“Terrible Pun of the Day”示例使用了最常見的 OAuth 2.0 流程，稱為“授權代碼”流程。
在我們深入了解 OAuth 正在做什么的更多詳細信息之前，讓我們映射一些 OAuth 術語。
 | 資源所有者：您！您是您的身份、數據以及可對您的賬戶執行的任何操作的所有者。 |
 | 客戶端：想要代表資源所有者訪問數據或執行操作的應用程序（例如“Terrible Pun of the Day”）。 |
 | 授權服務器：知道資源所有者的應用程序，其中資源所有者已經有一個帳戶。 |
 | 資源服務器：客戶端希望代表資源所有者使用的應用程序編程接口 （API） 或服務。 |
 | 重定向 URI：授權服務器在向客戶端授予權限后將資源所有者重定向回的 URL。這有時稱為 “Callback URL”。 |
 | 響應類型：客戶端希望接收的信息類型。最常見的響應類型是 ，其中 Client 需要 Authorization Code。code |
 | 范圍：這些是客戶端所需的精細權限，例如訪問數據或執行操作。 |
 | 同意：授權服務器采用客戶端請求的范圍，并與資源所有者驗證他們是否要授予客戶端權限。 |
 | 客戶端 ID：此 ID 用于標識具有授權服務器的客戶端。 |
 | 客戶端密鑰：這是只有客戶端和授權服務器知道的密鑰密碼。這使他們能夠在幕后安全地私下共享信息。 |
 | 授權碼：客戶端提供給授權服務器以換取訪問令牌的短期臨時代碼。 |
 | Access Token：客戶端將用于與 Resource Server 通信的密鑰。這類似于徽章或密鑰卡，授予客戶端代表您請求數據或向 Resource Server 執行操作的權限。 |
注意：有時 “Authorization Server” 和 “Resource Server” 是同一服務器。但是，在某些情況下，它們不會是同一服務器，甚至不是同一組織的一部分。例如，“Authorization Server”可能是“Resource Server”信任的第三方服務。
現在我們已經掌握了一些 OAuth 2.0 詞匯表，讓我們重新訪問該示例，仔細看看整個 OAuth 流程中發生了什么。
在您允許“每日糟糕雙關語”訪問您的聯系人之前很久，客戶端和授權服務器就已經建立了一種工作關系。授權服務器生成了一個客戶端ID和客戶端密鑰（有時也稱為應用ID和應用密鑰），并將它們提供給了客戶端，以便在未來的所有OAuth交換中使用。
顧名思義，Client Secret 必須保密，以便只有 Client 和 Authorization Server 知道它是什么。這就是 Authorization Server 驗證 Client 端的方式。
OAuth 2.0 僅用于授權，即允許一個應用訪問另一個應用的數據和功能。OpenID Connect (OIDC) 是在 OAuth 2.0 基礎上添加的一個薄層，它提供了關于登錄用戶的登錄信息和個人資料信息。建立登錄會話通常被稱為身份驗證，而關于登錄用戶（即資源所有者）的信息則被稱為身份。當授權服務器支持 OIDC 時，它有時被稱為身份提供者，因為它向客戶端提供關于資源所有者的信息。
OpenID Connect 支持跨多個應用程序使用一個登錄名的場景，也稱為單點登錄 （SSO）。例如，應用程序可以支持社交網絡服務（如 Facebook 或 Twitter）的 SSO，以便用戶可以選擇利用他們已經擁有并舒適使用的登錄名。
OpenID Connect 流看起來與 OAuth 相同。唯一的區別是，在初始請求中，使用了特定的范圍 ，而在最終交換中，Client 同時接收 Access Token 和 ID Token。openid
與 OAuth 流程一樣，OpenID Connect 訪問令牌是客戶端無法理解的值。就 Client 而言，Access Token 只是一串隨任何請求傳遞給 Resource Server 的亂碼，Resource Server 知道 Token 是否有效。但是，ID 令牌非常不同。
JWT 有時會被讀作“jots”。JWT 對你和我來說可能看起來像是一堆亂碼，但客戶端可以從 JWT 中提取嵌入的信息，如你的 ID、姓名、登錄時間、ID Token 的過期時間，以及是否有任何嘗試篡改 JWT 的行為。ID 令牌中的數據稱為聲明。
借助 OIDC，客戶端還可以通過一種標準方式使用訪問令牌從授權服務器請求其他身份信息，例如其電子郵件地址。
原文來源：https://developer.okta.com/blog/2019/10/21/illustrated-guide-to-oauth-and-oidc
