交互代碼的授權(quán)代碼（僅限身份引擎）。 | ? | ? |
| 信任 | 交互代碼 | ? | ? |
| 服務 | 客戶端憑證 | ? | ? |
注意：還有一個 OAuth 2.0 SAML 2.0 斷言流。此流程適用于希望使用現(xiàn)有信任關(guān)系而無需在授權(quán)服務器上執(zhí)行直接用戶批準步驟的客戶端應用程序。它支持 access 令牌和 ID 令牌。
OAuth 2.0 流的類型取決于您要構(gòu)建的客戶端類型。此流程圖可以快速幫助您決定使用哪個流程。
單頁應用（SPA）、移動應用和原生應用都屬于公開應用，終端用戶可以查看甚至可能修改應用的源代碼。代碼中的任何敏感信息都可能暴露給惡意用戶。相比之下，服務器端（Web）應用和桌面應用屬于機密或私有應用。機密客戶端可以使用客戶端認證方法，如客戶端密鑰和私鑰。
您的客戶使用的是重定向模型還是嵌入式模型？
重定向模型
如果您的 SPA 或本機應用程序?qū)⑸矸蒡炞C請求重定向到 Okta 托管的登錄頁面，請使用帶有 PKCE 的授權(quán)碼流程。
嵌入式模型
如果您的應用程序本身托管身份驗證流，請使用 Interaction Code 流。
一個在沒有直接終端用戶參與的服務器上運行的客戶端應用可以被信任為能夠負責任地使用其自身的憑據(jù)。如果您的客戶端應用僅進行機器到機器的交互，那么您應該使用客戶端憑據(jù)流（Client Credentials Flow）。
如果您既擁有某個應用，又擁有該應用所訪問的資源，那么這個應用就是高可信度的。因為您對這兩者都擁有所有權(quán)，所以您可以信任該應用能夠妥善處理終端用戶的用戶名和密碼。在這種情況下，并且僅當其他認證流程不可行時，您可以使用資源所有者密碼憑據(jù)流程（Resource Owner Password Credentials Flow，簡稱資源密碼流）。但是，該流程不支持多因素身份驗證，因此請考慮使用其他替代方案，如授權(quán)碼流程
如果您的應用程序不是高信任度，或者您想要利用多重身份驗證，則應使用授權(quán)代碼流程。
代碼交換的證明密鑰 （PKCE） 最初設計為保護移動應用程序中的授權(quán)代碼流的擴展。但是，它能夠防止授權(quán)代碼注入并保持流程安全，因此非常適合各種類型的 OAuth 客戶端。Okta 建議您盡可能將授權(quán)代碼流程與 PKCE 一起用于 OAuth 客戶端。
該流程要求您的應用生成一個加密隨機字符串，稱為代碼驗證程序。然后，對代碼驗證程序進行哈希處理以創(chuàng)建代碼質(zhì)詢，并且此質(zhì)詢與授權(quán)代碼請求一起傳遞。授權(quán)服務器使用授權(quán)碼進行響應，并將代碼質(zhì)詢與授權(quán)碼相關(guān)聯(lián)。
應用程序收到授權(quán)碼后，它會在訪問令牌請求中發(fā)送授權(quán)碼和代碼驗證器。授權(quán)服務器使用先前商定的哈希算法重新計算驗證程序的質(zhì)詢。然后，授權(quán)服務器將挑戰(zhàn)碼與之前與授權(quán)碼關(guān)聯(lián)的挑戰(zhàn)碼進行比較。如果兩個挑戰(zhàn)碼和驗證器相匹配，授權(quán)服務器就知道這兩個請求是由同一個客戶端發(fā)送的。
交互代碼流程擴展了 OAuth 2.0 和 OIDC 標準。它要求客戶端將客戶端 ID 和 PKCE 參數(shù)傳遞給 Okta，以確保流的安全。用戶可以用最少的信息啟動請求，依靠客戶端來促進與 Okta 的交互以驗證用戶身份。
注意：交互代碼流僅在 Identity Engine 組織中可用。
資源所有者密碼流適用于以下使用案例：
它最常見于為在線服務制作的第一方客戶端中，比如與Facebook服務交互的Facebook客戶端應用。它不需要像授權(quán)碼流程或隱式流程那樣進行重定向，而是只涉及對端點的一次經(jīng)過身份驗證的調(diào)用。/token
客戶端憑據(jù)流適用于沒有最終用戶的服務器端（機密）客戶端應用程序。通常，這意味著機器對機器的通信。該應用需要是服務器端應用，因為它必須能夠安全地保管客戶端密鑰。由于憑證是硬編碼的，因此實際的終端用戶無法使用它。該流程涉及向端點發(fā)送一個經(jīng)過身份驗證的請求，該請求將返回一個訪問令牌。/token
注意：客戶端憑證流不支持刷新令牌。
此流程適用于無需在授權(quán)服務器上直接獲取用戶批準，而是利用現(xiàn)有信任關(guān)系的客戶端應用。它允許客戶端應用從SAML身份提供者（Identity Provider）處獲得一個有效且已簽名的SAML斷言，并以此斷言來從OAuth授權(quán)服務器處獲取一個OAuth訪問令牌。例如，當您希望從僅支持委托權(quán)限而無需提示用戶輸入憑據(jù)的API中檢索數(shù)據(jù)時，此流程就非常有用。
要使用 SAML 2.0 斷言作為授權(quán)授予，客戶端需要向身份提供商發(fā)出 SAML 請求。然后，身份提供商在響應中發(fā)送回 SAML 2.0 斷言。然后，客戶端請求具有授權(quán)類型的訪問令牌并包含該參數(shù)。該參數(shù)的值是 Base64 編碼的 SAML 2.0 斷言。在該請求中，您只能發(fā)送一個 SAML 斷言。urn:ietf:params:oauth:grant-type:saml2-bearerassertionassertion
注意：隱式流是僅用于不支持 PKCE 的 SPA 的舊流。
隱式流程（Implicit Flow）旨在為不支持跨源資源共享（CORS）的基于瀏覽器的應用而設計。此外，它還適用于缺乏現(xiàn)代加密API且無法保護客戶端密鑰的基于瀏覽器的應用。在此流程中，客戶端不會向端點發(fā)送請求，而是在從端點重定向的過程中接收訪問令牌?？蛻舳吮仨毮軌蚺c資源所有者的用戶代理交互，并接收來自授權(quán)服務器的傳入請求（通過重定向）。/token/authorize
注意：由于 Implicit 流始終適用于不太受信任的客戶端，因此它不支持刷新令牌。
重要：對于在支持 Web Crypto for PKCE 的現(xiàn)代瀏覽器中運行的單頁應用程序 （SPA），Okta 建議將授權(quán)代碼流程與 PKCE 一起使用。使用此流而不是 Implicit 流以獲得最大的安全性。如果需要支持較舊的瀏覽器，隱式流將提供功能性解決方案。
原文來源：https://developer.okta.com/docs/concepts/oauth-openid/