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