欧美在线,亚洲综合,日韩av片无码一区二区三区不卡

Authorization: SSWS <api_token_value>
Accept: application/json
Host: dev-1234567.okta.com

API的調(diào)用者（又稱(chēng)客戶(hù)端）將令牌值添加到調(diào)用中。根據(jù)調(diào)用的供應(yīng)商系統(tǒng)，API可能會(huì)將靜態(tài)令牌值添加到 HTTP 標(biāo)頭，如授權(quán)（使用標(biāo)準(zhǔn)授權(quán)方案或?qū)Ｓ惺跈?quán)方案，如 Okta 的 SSWS 方案），或添加到查詢(xún)參數(shù)中。

從靜態(tài) API 標(biāo)記轉(zhuǎn)向 OAuth 2.0，以提高安全性

與許多技術(shù)一樣，這種易用性也會(huì)相應(yīng)增加風(fēng)險(xiǎn)。與壽命較短的 OAuth 2.0 令牌不同，靜態(tài)令牌的壽命通常較長(zhǎng)。設(shè)置在查詢(xún)參數(shù)中的 API 標(biāo)記尤其危險(xiǎn)。瀏覽器會(huì)將 URL 保存在歷史記錄中，日志系統(tǒng)可能會(huì)記錄整個(gè) URL，從而比使用 HTTP 標(biāo)頭更容易暴露令牌。

為了更好地理解與靜態(tài) API 令牌相關(guān)的安全問(wèn)題，讓我們來(lái)詳細(xì)研究它們的一些特性，并與作為替代方案的 OAuth 2.0 進(jìn)行對(duì)比。

使用靜態(tài)API令牌時(shí)的訪(fǎng)問(wèn)風(fēng)險(xiǎn)

靜態(tài)令牌可能落入壞人之手，導(dǎo)致未經(jīng)授權(quán)的訪(fǎng)問(wèn)。例如，靜態(tài)令牌可能無(wú)意中被檢查到源代碼控制系統(tǒng)中，從而無(wú)意中將令牌暴露給版本庫(kù)查看器和源代碼控制歷史。由于靜態(tài)令牌的壽命較長(zhǎng)，因此令牌暴露的風(fēng)險(xiǎn)尤其令人擔(dān)憂(yōu)，因?yàn)楸槐I令牌的后果會(huì)造成嚴(yán)重影響——被盜的靜態(tài)令牌在手動(dòng)停用或最終過(guò)期之前一直處于激活狀態(tài)，從而允許未經(jīng)授權(quán)的訪(fǎng)問(wèn)。

代幣輪換問(wèn)題

旋轉(zhuǎn)靜態(tài)令牌是一項(xiàng)具有挑戰(zhàn)性的任務(wù)。由于令牌值會(huì)在調(diào)用者的環(huán)境或軟件系統(tǒng)中持續(xù)存在，因此要在保持生產(chǎn)環(huán)境正常運(yùn)行的情況下快速釋放令牌、生成新的令牌并保存令牌，這對(duì)輪換的時(shí)間安排提出了挑戰(zhàn)。

難以限制范圍

為靜態(tài)令牌分配有限的作用域并不簡(jiǎn)單。靜態(tài)令牌通常授予對(duì)所調(diào)用 API 的全部訪(fǎng)問(wèn)權(quán)限–一種全有或全無(wú)的訪(fǎng)問(wèn)級(jí)別。為有限范圍定義訪(fǎng)問(wèn)權(quán)限（如只讀訪(fǎng)問(wèn)權(quán)限與寫(xiě)入訪(fǎng)問(wèn)權(quán)限）以及其他細(xì)粒度訪(fǎng)問(wèn)控制措施，可能無(wú)法通過(guò)靜態(tài) API 標(biāo)記來(lái)實(shí)現(xiàn)或難以管理。

用戶(hù)生成的令牌中的繼承權(quán)限

用戶(hù)生成的訪(fǎng)問(wèn)令牌通常采用生成令牌的用戶(hù)賬戶(hù)權(quán)限。如果一個(gè)管理員生成了令牌，那么它就可以完全訪(fǎng)問(wèn)管理員可以執(zhí)行的所有資源和操作。為了減輕這種擔(dān)憂(yōu)，有時(shí)企業(yè)會(huì)設(shè)置范圍有限的服務(wù)賬戶(hù)來(lái)生成令牌。然而，這樣做會(huì)導(dǎo)致用戶(hù)管理費(fèi)用增加，并有可能占用許可證。

審計(jì)挑戰(zhàn)

跟蹤靜態(tài)令牌的使用情況非常棘手。審計(jì)的核心需求是跟蹤用戶(hù)與 API 的交互。但是，靜態(tài) API 標(biāo)記通常沒(méi)有用戶(hù)上下文，而且對(duì) API 的所有調(diào)用都使用相同的靜態(tài)標(biāo)記，因此可能無(wú)法識(shí)別特定用戶(hù)對(duì) API 的操作。

靜態(tài)令牌很脆弱

當(dāng)用戶(hù)退出組織時(shí)，與用戶(hù)賬戶(hù)關(guān)聯(lián)的令牌就會(huì)失效。有些組織使用服務(wù)賬戶(hù)來(lái)抵消這一措施，但這會(huì)帶來(lái)訪(fǎng)問(wèn)風(fēng)險(xiǎn)和管理開(kāi)銷(xiāo)。

有一種更好、更安全的方法可以訪(fǎng)問(wèn) API，從而降低與靜態(tài) API 標(biāo)記相關(guān)的風(fēng)險(xiǎn)：使用行業(yè)標(biāo)準(zhǔn) OAuth 2.0 流程。

擁抱 OAuth 2.0 以提高安全性

OAuth 2.0 幾乎可以滿(mǎn)足任何場(chǎng)景的需求，以取代靜態(tài)令牌（如 Okta 的 SSWS 令牌）。但與靜態(tài)令牌不同的是，OAuth 規(guī)范包括令牌輪換、基本授權(quán)決定等日常使用案例所必需的定義和安全實(shí)踐，例如：

服務(wù)與服務(wù)之間的自動(dòng)交互，用于在沒(méi)有用戶(hù)上下文的情況下處理幕后 API 調(diào)用
通過(guò)命令行操作實(shí)現(xiàn)基于任務(wù)的自動(dòng)化
根據(jù)用戶(hù)的訪(fǎng)問(wèn)級(jí)別限制應(yīng)用程序數(shù)據(jù)和操作，以保持授權(quán)安全性

OAuth 2.0 通過(guò)向集中式授權(quán)服務(wù)器發(fā)送請(qǐng)求中的配置屬性，支持上述每種日常使用情況。一般的交互是這樣一個(gè)多步驟過(guò)程：

調(diào)用者向授權(quán)服務(wù)器請(qǐng)求一個(gè)訪(fǎng)問(wèn)令牌，并傳遞用例所需的配置屬性。授權(quán)服務(wù)器返回一個(gè)短期訪(fǎng)問(wèn)令牌。令牌的壽命取決于用例。有些用例本質(zhì)上更安全，因此使用期限會(huì)有所不同。下面的 HTTP 請(qǐng)求顯示了一個(gè)檢索令牌的請(qǐng)求示例，但不包括所需的配置屬性。你將在接下來(lái)的示例中看到必要的配置屬性。

POST  /token HTTP/1.1

Host: authorization-server.com



<plus required configuration properties + credentials>

調(diào)用者使用 API 請(qǐng)求中的令牌值作為 HTTP 請(qǐng)求的授權(quán)頭中的值，并使用承載器方案。HTTP 請(qǐng)求的內(nèi)容如下：

GET /api/products HTTP/1.1

Authorization: Bearer <api_token_value>

Accept: application/json

Host: dev-1234567.okta.com

OAuth 2.0 的內(nèi)容非常豐富，因此請(qǐng)查看本文章末尾的資源以了解更深入的內(nèi)容。我們不會(huì)在這篇文章中深入探討所有細(xì)節(jié)，但會(huì)針對(duì)所提到的用例提供具體信息，并為每個(gè)用例提供高級(jí)摘要。

讓我們看看每個(gè)用例，了解 OAuth 2.0 如何支持這些用例。

服務(wù)與服務(wù)之間的互動(dòng)

您可能有調(diào)用其他應(yīng)用程序接口獲取數(shù)據(jù)或執(zhí)行操作的后端流程。OAuth 2.0 支持服務(wù)對(duì)服務(wù)或機(jī)器對(duì)機(jī)器的請(qǐng)求，而不需要使用稱(chēng)為 “客戶(hù)端憑證 “的授權(quán)流來(lái)關(guān)聯(lián)調(diào)用的用戶(hù)上下文。

使用客戶(hù)端憑據(jù)相對(duì)于 API 令牌的優(yōu)勢(shì)

與靜態(tài) API 密鑰相比，使用 OAuth 2.0 進(jìn)行服務(wù)間交互具有巨大優(yōu)勢(shì)，尤其是在稱(chēng)為作用域的訪(fǎng)問(wèn)級(jí)別方面。在 OAuth 2.0 中，您可以將訪(fǎng)問(wèn)令牌獲取的作用域作為調(diào)用配置屬性的一部分來(lái)識(shí)別，以檢索您的令牌。您需要確保您調(diào)用的 API 支持基于作用域的訪(fǎng)問(wèn)，并且您已經(jīng)授予了所需作用域的訪(fǎng)問(wèn)權(quán)限。例如，Okta API為資源API定義了多個(gè)作用域，如okta.users.read和okta.users.write。您可以授予其中一個(gè)或兩個(gè)作用域的訪(fǎng)問(wèn)權(quán)限。

客戶(hù)端憑證流程與使用服務(wù)賬戶(hù)進(jìn)行 API 授權(quán)不同。OAuth 2.0 支持以標(biāo)準(zhǔn)格式進(jìn)行機(jī)器到機(jī)器的交互，而無(wú)需占用用戶(hù)席位來(lái)模擬自動(dòng)化用戶(hù)。請(qǐng)注意，當(dāng)你定義作用域時(shí)，是在服務(wù)應(yīng)用程序的配置和授權(quán)服務(wù)器中定義的，而不是在用戶(hù)級(jí)別定義的。這樣做的好處是，你可以控制整個(gè)服務(wù)應(yīng)用程序的資源訪(fǎng)問(wèn)，而不是通過(guò)應(yīng)用程序中的某個(gè)用戶(hù)。您不必再擔(dān)心服務(wù)賬戶(hù)的管理問(wèn)題，而且可以確信應(yīng)用程序訪(fǎng)問(wèn)的范圍不會(huì)超過(guò)您所允許的范圍。

使用客戶(hù)端憑據(jù)檢索訪(fǎng)問(wèn)令牌

要檢索此流程的訪(fǎng)問(wèn)令牌，需要發(fā)送指定授權(quán)流程類(lèi)型、憑據(jù)和訪(fǎng)問(wèn)令牌作用域的屬性。定義授權(quán)流的 OAuth 2.0 術(shù)語(yǔ)稱(chēng)為 grant_type；對(duì)于客戶(hù)憑據(jù)流，你要傳遞的值是 client_credentials。

憑證可以是用客戶(hù)端私鑰簽名的加密安全 JSON Web 令牌（JWT），也可以是從授權(quán)服務(wù)器生成的秘密值。私鑰 JWT 更為安全，因?yàn)槟悴粫?huì)冒著暴露秘密值的風(fēng)險(xiǎn)，從而意外地創(chuàng)建與靜態(tài) API 令牌類(lèi)似的訪(fǎng)問(wèn)問(wèn)題。您將生成一對(duì)公鑰/私鑰，并在 JSON 網(wǎng)絡(luò)密鑰集 (JWKS) 中注冊(cè)公鑰或?qū)⑵渖蟼鞯绞跈?quán)服務(wù)器，這樣授權(quán)服務(wù)器就有了驗(yàn)證 JWT 簽名的公鑰。有關(guān)此過(guò)程的更多信息，請(qǐng)參閱通過(guò)服務(wù)應(yīng)用程序?yàn)?Okta 實(shí)施 OAuth 文檔。

用于檢索訪(fǎng)問(wèn)令牌的 HTTP 調(diào)用示例可能如下所示：

POST  /token HTTP/1.1

Content-Type: application/x-www-form-urlencoded

Accept: application/json

Host: authorization-server.com



grant_type=client_credentials

&scope=okta.users.read

&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer

&client_assertion=<generated_jwt>

獲得訪(fǎng)問(wèn)令牌后，您可以將其作為標(biāo)頭添加到 API 調(diào)用中：Authorization: Bearer access_token

了解更多有關(guān)使用 .NET 進(jìn)行服務(wù)對(duì)服務(wù) API 調(diào)用和在 Python 中創(chuàng)建私有 JWT 的信息，請(qǐng)參閱《保護(hù)您的 .NET 6 Web API》和《在三個(gè) Python 命令中設(shè)置私鑰 JWT 流程》。

基于任務(wù)的自動(dòng)化

命令行終端（如 Bash 和 PowerShell）是在終端窗口內(nèi)運(yùn)行單個(gè)命令或腳本的無(wú)瀏覽器進(jìn)程。與之前的服務(wù)間交互不同，該流程涉及用戶(hù)上下文。您希望在授權(quán)上下文下運(yùn)行命令行操作，這意味著您只能訪(fǎng)問(wèn)您應(yīng)該擁有的 API 資源。OAuth 2.0 通過(guò)一個(gè)名為設(shè)備流（Device Flow）的流程支持這種用例。

在此流程中，獲取訪(fǎng)問(wèn)令牌是一個(gè)多步驟過(guò)程。在像服務(wù)對(duì)服務(wù)用例那樣直接請(qǐng)求訪(fǎng)問(wèn)令牌之前，首先要將客戶(hù) ID 發(fā)送到授權(quán)服務(wù)器上的一個(gè)特殊端點(diǎn)，從而獲得唯一的驗(yàn)證碼：

POST  /device/authorize HTTP/1.1

Content-Type: application/x-www-form-urlencoded

Host: authorization-server.com 



client_id=<client_ID>

/device/authorize 調(diào)用的響應(yīng)會(huì)返回兩個(gè)唯一代碼（設(shè)備代碼和用戶(hù)代碼）和一個(gè)驗(yàn)證 URI。通過(guò)瀏覽器導(dǎo)航到驗(yàn)證 URI 并輸入用戶(hù)代碼，確認(rèn)授權(quán)請(qǐng)求。

要檢索訪(fǎng)問(wèn)令牌，需要在調(diào)用中添加 grant_type 屬性，以指定用例的 OAuth 2.0 流程和設(shè)備代碼作為配置屬性：

POST  /token HTTP/1.1

Content-Type: application/x-www-form-urlencoded

Host: authorization-server.com



client_id=<client_ID>

&grant_type=urn:ietf:params:oauth:grant-type:device_code

&device_code=device_code

在 Authorization.Bearer access_token 頭信息中使用響應(yīng)中的訪(fǎng)問(wèn)令牌：Bearer access_token 頭信息。

有關(guān)命令行設(shè)備代碼流程的更多信息，請(qǐng)參閱《使用 Java 從命令行進(jìn)行身份驗(yàn)證》（Authenticate from the Command Line with Java）。

用戶(hù)通過(guò) Web 應(yīng)用程序訪(fǎng)問(wèn)

最后一個(gè)用例確保用戶(hù)的授權(quán)適用于使用網(wǎng)絡(luò)應(yīng)用程序時(shí)的 API 訪(fǎng)問(wèn)。OAuth 2.0 支持將應(yīng)用程序的操作限制在用戶(hù)可以進(jìn)行的操作和看到的數(shù)據(jù)的子集范圍內(nèi)。在此流程中，您可以使用用戶(hù)上下文來(lái)申請(qǐng)資源授權(quán)，此外，有了用戶(hù)上下文，對(duì)單個(gè)用戶(hù)調(diào)用的審計(jì)和跟蹤也會(huì)變得更加簡(jiǎn)單。此用例的 OAuth 2.0 流程結(jié)合了標(biāo)準(zhǔn)流程、授權(quán)代碼流程和一個(gè)額外安全層的擴(kuò)展，稱(chēng)為代碼交換證明密鑰（PKCE）。

帶有 PKCE 的授權(quán)代碼流需要多個(gè)步驟才能檢索訪(fǎng)問(wèn)令牌，并涉及通過(guò)同意和驗(yàn)證進(jìn)行的用戶(hù)交互，從而實(shí)現(xiàn)多因素身份驗(yàn)證。在此流程中，您將把用戶(hù)重定向到授權(quán)服務(wù)器，在請(qǐng)求訪(fǎng)問(wèn)令牌之前獲取授權(quán)碼。

重定向 URL 包含特定于請(qǐng)求的屬性，以便用戶(hù)完成登錄，包括使用 response type 屬性指定請(qǐng)求類(lèi)型和客戶(hù)端 ID 等屬性。

https://<identity_provider_uri>/authorize?response_type=code&client_id=<client_ID>&+remaining props

當(dāng)用戶(hù)成功完成登錄后，身份提供程序會(huì)重定向到應(yīng)用程序，并在授權(quán)響應(yīng)中提供授權(quán)代碼。要檢索訪(fǎng)問(wèn)令牌，需要輸入該流程的授權(quán)類(lèi)型、授權(quán)代碼和其他特定于請(qǐng)求的元數(shù)據(jù)。

POST  /token HTTP/1.1

Host: authorization-server.com



grant_type=code

&code=<code_response>

&client_id=<client_ID>

有了訪(fǎng)問(wèn)令牌后，網(wǎng)絡(luò)應(yīng)用程序就可以在 “授權(quán)”（Authorization：Bearer access_token 標(biāo)頭。

有關(guān)授權(quán)代碼流的更多信息，請(qǐng)參閱《SPA 的身份驗(yàn)證和授權(quán)工作原理》和《將 PKCE 與 OAuth 2.0 和 Spring Boot 結(jié)合使用以提高安全性》。

逐步淘汰靜態(tài) API 令牌并使用 OAuth 2.0

軟件遷移需要時(shí)間和規(guī)劃，制定一個(gè)好的游戲計(jì)劃會(huì)有所幫助。考慮以小步漸進(jìn)的方式過(guò)渡到 OAuth 2.0。

從靜態(tài) API 標(biāo)記遷移的第一步是確保您使用的 API 支持 OAuth 2.0。如果要調(diào)用第三方 API，請(qǐng)向供應(yīng)商咨詢(xún)。如果您的 API 是內(nèi)部 API，則需要添加 OAuth 支持。一旦驗(yàn)證您調(diào)用的 API 支持 OAuth，您就需要 OAuth 應(yīng)用程序的客戶(hù)端 ID，并啟用訪(fǎng)問(wèn)措施（如作用域）。

以管理員身份登錄到 Okta 管理控制臺(tái)后，您就可以確定是否在 Okta 環(huán)境中使用靜態(tài) API 標(biāo)記。在側(cè)邊欄中，導(dǎo)航到 “安全性”>”API”，然后選擇 “令牌 “選項(xiàng)卡，就可以看到為 Okta 組織創(chuàng)建的所有令牌。通過(guò)該視圖可以了解 API 令牌的使用情況、用例和訪(fǎng)問(wèn)級(jí)別（例如，超級(jí)管理員創(chuàng)建的令牌具有完全訪(fǎng)問(wèn)權(quán)）。您需要對(duì)每個(gè)令牌進(jìn)行評(píng)估，并將其轉(zhuǎn)換為使用 OAuth。

讓我們重點(diǎn)關(guān)注自動(dòng)服務(wù)對(duì)服務(wù)調(diào)用的用例。將 OAuth 2.0 集成到您的應(yīng)用程序接口中是一件非常困難的事情，因此讓我們來(lái)看看如何逐步實(shí)現(xiàn)這一目標(biāo)。在進(jìn)行任何代碼修改之前，您可以在本地手動(dòng)嘗試這些步驟，并使用您最喜歡的 HTTP 客戶(hù)端請(qǐng)求一個(gè)令牌，然后使用 OAuth 2.0 調(diào)用 API。本例使用帶有私鑰 JWT 的客戶(hù)端憑證流。步驟如下

生成公鑰/私鑰對(duì)
使用公鑰/私鑰對(duì)生成私鑰 JWT
請(qǐng)求訪(fǎng)問(wèn)令牌
將訪(fǎng)問(wèn)令牌添加到 API 請(qǐng)求中
將 OAuth 納入應(yīng)用系統(tǒng)

生成公鑰/私鑰對(duì)

您可以按照以下說(shuō)明生成一對(duì)公鑰/私鑰。如果您不想自己生成公鑰對(duì)，Okta 的管理控制臺(tái)可以生成一個(gè)公鑰對(duì)/私鑰對(duì)用于測(cè)試。

生成私鑰JWT

按照 “使用服務(wù)應(yīng)用程序?yàn)?Okta 實(shí)施 OAuth “文檔中的說(shuō)明，使用公鑰/私鑰對(duì)創(chuàng)建私鑰 JWT。在這一步，更重要的是了解這一切是如何工作的，而不是自動(dòng)執(zhí)行步驟，因此您可以將公/私鑰對(duì)存儲(chǔ)在本地，使用安裝在您機(jī)器上的工具，并將包含您公鑰的 JWKS 粘貼到測(cè)試 JWT 生成器網(wǎng)站上。

請(qǐng)求訪(fǎng)問(wèn)令牌

使用你的私鑰 JWT 請(qǐng)求訪(fǎng)問(wèn)令牌，在你喜歡的 HTTP 客戶(hù)端中發(fā)出 HTTP 請(qǐng)求，不要添加任何作用域。在沒(méi)有適當(dāng)作用域的情況下使用訪(fǎng)問(wèn)令牌時(shí)應(yīng)該會(huì)出錯(cuò)，但測(cè)試出錯(cuò)和路徑正確是好事。訪(fǎng)問(wèn)令牌會(huì)在某個(gè)時(shí)間過(guò)期，你會(huì)在訪(fǎng)問(wèn)令牌響應(yīng)中看到過(guò)期時(shí)間。訪(fǎng)問(wèn)令牌是響應(yīng)的一部分。您將使用整個(gè)字符串作為訪(fǎng)問(wèn)令牌。

將訪(fǎng)問(wèn)令牌添加到您的 API 請(qǐng)求中

使用 HTTP 客戶(hù)端，使用訪(fǎng)問(wèn)令牌調(diào)用 API。您將添加一個(gè)授權(quán)標(biāo)頭并使用承載器方案，這樣您的 API 調(diào)用就會(huì)有如下格式的標(biāo)頭：

Authorization: Bearer <access_token>

調(diào)用 API 時(shí)，您應(yīng)該會(huì)收到 HTTP 狀態(tài)為 403 的錯(cuò)誤信息。耶！成功了嗎？是的，一次成功的錯(cuò)誤案例測(cè)試?，F(xiàn)在您知道如果配置范圍時(shí)出現(xiàn)錯(cuò)誤會(huì)出現(xiàn)什么錯(cuò)誤了。讓我們把作用域添加到訪(fǎng)問(wèn)令牌請(qǐng)求中，然后再試一次。

這次，使用私鑰 JWT 申請(qǐng)?jiān)L問(wèn)令牌，并為 API 調(diào)用添加作用域。在 API 調(diào)用中使用訪(fǎng)問(wèn)令牌。真相時(shí)刻！你應(yīng)該看到一個(gè)成功的響應(yīng)。如果再次出現(xiàn) 403 錯(cuò)誤，就說(shuō)明存在配置錯(cuò)誤。如果出現(xiàn)這種情況，請(qǐng)仔細(xì)檢查請(qǐng)求作用域，并確保 OAuth 2.0 應(yīng)用程序已啟用您請(qǐng)求的作用域。

在系統(tǒng)中添加OAuth 2.0授權(quán)

現(xiàn)在，您已經(jīng)成功地手動(dòng)完成了服務(wù)器到服務(wù)調(diào)用的 OAuth 2.0 授權(quán)，可以將這些步驟的各個(gè)方面引入您的系統(tǒng)。在開(kāi)發(fā)或測(cè)試環(huán)境中，嘗試使用訪(fǎng)問(wèn)令牌。您需要更改 API 以使用帶承載器方案格式的授權(quán)標(biāo)頭，并用手動(dòng)生成的訪(fǎng)問(wèn)令牌替換現(xiàn)有的靜態(tài) API 令牌，以確保您的 API 調(diào)用在不自動(dòng)請(qǐng)求訪(fǎng)問(wèn)令牌的情況下也能正常工作。

當(dāng)您確信 API 系統(tǒng)能成功處理訪(fǎng)問(wèn)令牌時(shí)，就可以在代碼中添加請(qǐng)求訪(fǎng)問(wèn)令牌的步驟了。您的技術(shù)?？赡苡?SDK，至少可以協(xié)助完成部分（或全部）請(qǐng)求步驟。Okta 的管理 SDK 可以代表您處理 OAuth 2.0 握手。Java Spring 用戶(hù)可以查看 Spring Security 文檔，.NET Core 用戶(hù)可以查看 Microsoft.AspNetCore.Authentication 作為示例。請(qǐng)記住，在進(jìn)行過(guò)程中要測(cè)試您的工作是否順利、是否存在錯(cuò)誤案例以及是否正確處理了訪(fǎng)問(wèn)令牌過(guò)期等情況。

在將更改部署到生產(chǎn)環(huán)境之前，請(qǐng)確保使用生產(chǎn)質(zhì)量工具在內(nèi)部生成 JWKS 并安全地管理私鑰。

API授權(quán)遷移期間的最佳實(shí)踐

立即從靜態(tài)令牌過(guò)渡并不總是可行，特別是在大型組織中或者如果您有大量 API 需要更新。如果您仍在 Okta 中使用 SSWS 令牌，那么您希望在過(guò)渡到 OAuth 2.0 之前降低風(fēng)險(xiǎn)。最佳實(shí)踐包括：

使用 OAuth 2.0 實(shí)施新的 API 調(diào)用或代碼。
遵循最小特權(quán)原則。例如：

不要使用個(gè)人帳戶(hù)建立服務(wù)帳戶(hù)。

對(duì)服務(wù)帳戶(hù)使用自定義管理員角色，僅授予基本權(quán)限。

使用組和全局會(huì)話(huà)策略來(lái)防止服務(wù)帳戶(hù)的交互式登錄。

使用 OAuth 2.0 保護(hù) API 調(diào)用

從靜態(tài)令牌轉(zhuǎn)向 OAuth 2.0 不僅僅是為了擁抱新技術(shù)，更是為了轉(zhuǎn)向一個(gè)更安全、更靈活、對(duì)開(kāi)發(fā)人員更友好的生態(tài)系統(tǒng)。雖然靜態(tài)令牌有其存在的時(shí)間和位置，但很明顯，未來(lái)將是動(dòng)態(tài)的、以用戶(hù)為中心的、安全的 OAuth 2.0 解決方案。

請(qǐng)記住，隨著技術(shù)的進(jìn)步，保持更新并適應(yīng)更好的實(shí)踐不僅有益，而且至關(guān)重要。遷移到 OAuth 2.0，踏上更安全、更簡(jiǎn)化、更高效的開(kāi)發(fā)之旅。

OAuth 2.0 的后續(xù)步驟

如果您覺(jué)得這篇文章有趣，您可能會(huì)喜歡這些帖子。

查看 Okta 的API 安全開(kāi)發(fā)人員指南，開(kāi)始遷移到 OAuth 2.0：

配置展示所有權(quán)證明

本指南討論如何創(chuàng)建發(fā)送者限制的訪(fǎng)問(wèn)令牌，這是一種應(yīng)用程序級(jí)機(jī)制，用于防止不同端點(diǎn)處的令牌重放。

為 Okta 配置 OAuth

本指南介紹如何使用范圍內(nèi)的 OAuth 2.0 訪(fǎng)問(wèn)令牌與 Okta API 進(jìn)行交互。?為 Okta 配置 OAuth：服務(wù)應(yīng)用程序
本指南介紹如何使用服務(wù)應(yīng)用程序的作用域 OAuth 2.0 訪(fǎng)問(wèn)令牌與 Okta API 進(jìn)行交互。

保護(hù)您的 API 端點(diǎn)

使用 Okta 添加授權(quán)來(lái)保護(hù)您的 API。完成后，您將擁有一個(gè)安全的 REST API 應(yīng)用程序，用于驗(yàn)證傳入請(qǐng)求。

整合第三方風(fēng)險(xiǎn)

本指南介紹如何配置 Okta 組織以接收來(lái)自第三方提供商的風(fēng)險(xiǎn)事件。使用 OAuth 2.0 組織之間的安全 API 連接
本指南介紹如何在多租戶(hù)解決方案中使用 OAuth 2.0 安全地設(shè)置 Okta 中心和輻射組織以同步用戶(hù)和組。使用Org2Org 集成應(yīng)用程序的 OAuth 2.0 客戶(hù)端憑證流將 Okta org API 訪(fǎng)問(wèn)連接到范圍數(shù)據(jù)。

使用 ACR 值設(shè)置逐步身份驗(yàn)證