Thinktecture Identity Server客戶端選擇和實現

Question

我正在嘗試通過身份服務器將自己的頭腦從雲端移開。

我想實施身份服務器項目以進行身份​​驗證

1. 一個ASP.NET MVC 5應用程序
2. ASP.NET Web API
3. Windows服務實現

在這篇博文中，我已經閱讀了一些有關客戶的詳細信息。 作者只聲明：

OAuth 2針對不同的用例提供了幾種“授權類型”。 定義的授予類型為：

1. 在Web服務器上運行的應用的授權碼
2. 隱含於基於瀏覽器或移動應用程序
3. 使用用戶名和密碼登錄的密碼
4. 用於應用程序訪問的客戶端憑據

授權代碼和隱式代碼有什么區別？ 這是否意味着javascript代碼應使用隱式代碼？

正確地說我需要：

1. ASP.NET MVC應用程序的密碼授予
2. Web API的客戶端憑據
3. Windows服務的授權碼？

另一個問題是，我想基於承載令牌和簡單的apiKey在我的Web api中實現授權。 兩種類型都能凝聚嗎？ 如何通過使用身份服務器實現apiKey？

非常感謝，如果這些是愚蠢的問題，請原諒。

Answer 1

我盡力使這個答案簡短（但是我被迫添加大量上下文來理解答案）

機密與公共客戶

客戶端（代表您請求訪問的應用程序-MVC App，SPA等）基於其通過授權服務器（在本例中為Identity Server）進行安全身份驗證的能力，分為保密客戶端和公共客戶端。

例如，Web應用程序（MVC App）被視為機密客戶端，因為它是在安全服務器上實現的，並且能夠通過授權服務器（通過反向通道-無需用戶代理或公共通道參與）進行安全的客戶端身份驗證。 而且，它可以維護秘密令牌（本質上是客戶端憑據，access_token和刷新令牌），這些令牌不受公共訪問的保護（例如，由用戶代理/資源所有者使用）

而基於用戶代理的應用程序（SPA）和本機應用程序（移動應用程序）被視為公共客戶端。 這是因為資源所有者可以輕松訪問協議數據和客戶端憑據。

授權碼授予

Oauth2規范將授權代碼授予定義為：

授權碼授予類型用於獲取訪問令牌和刷新令牌，並且針對機密客戶端進行了優化。 由於這是基於重定向的流程，因此客戶端必須能夠與資源所有者的用戶代理（通常是Web瀏覽器）進行交互，並能夠（通過重定向）接收來自授權服務器的傳入請求。”

簡而言之，授權代碼流針對通過用戶代理（瀏覽器）與資源所有者進行交互的機密客戶端進行了優化，該代理能夠接收和重定向來自Auth Server（身份服務器）的傳入請求。

簡而言之–授權碼流程具有以下順序，

• 資源所有者（通過–用戶代理）通過授權服務器進行身份驗證，並獲得一個authorization_code
• 資源所有者（從授權服務器重定向后，通過用戶代理）向客戶端提供Authorization_code
• 客戶端（通過反向通道請求）通過授權服務器進行身份驗證，並交換Authorization_code以獲取access_token
• access_token存儲在客戶端中，資源所有者重定向到適當的資源
• 由於客戶端（MVC App）具有access_token，因此它可以從授權服務器請求刷新令牌（如果需要）。
• 但是，有一點很重要-在授權代碼流中，資源所有者永遠不會看到（或訪問）Access_token。 客戶端安全地存儲它。

隱性補助

Oauth2規范將隱式授予定義為：

“隱式授權類型用於獲取訪問令牌（它不支持刷新令牌的發布），並且針對已知操作特定重定向URI的公共客戶端進行了優化。 這些客戶端通常是在瀏覽器中使用腳本語言（例如JavaScript）實現的。

由於這是基於重定向的流程，因此客戶端必須能夠與資源所有者的用戶代理（通常是Web瀏覽器）進行交互，並且能夠（通過重定向）接收來自授權服務器的傳入請求。

與授權代碼授予類型不同，在授權類型授予類型中，客戶端分別提出授權請求和訪問令牌請求，客戶端接收訪問令牌作為授權請求的結果。

隱式授予類型不包括客戶端身份驗證，而是依賴於資源所有者的存在和重定向URI的注冊。 由於訪問令牌已編碼到重定向URI中，因此它可能會暴露給資源所有者和駐留在同一設備上的其他應用程序”

授權代碼和隱式代碼之間的區別？

所以主要的區別是：

• 在隱式授予中，客戶端不會單獨發出授權和訪問令牌請求。
• 授權令牌和訪問令牌都傳遞給資源所有者，並編碼到重定向URI中
• 這導致此處描述的安全漏洞https://tools.ietf.org/html/rfc6749#section-10.16
• 由於這些安全隱患，通過體系結構，不會將刷新令牌發布給公共客戶端（由於無法維護客戶端機密，因此需要訪問令牌和刷新令牌）

這是否意味着javascript代碼應使用隱式代碼？

是。 由於上面討論的細節，並且作為慣例，大多數JS / SPA使用Oauth2隱式流來保護應用程序。

（ 為避免混淆，請跳過此部分。此隱式流程有多種變體。總體而言，Oauth2規范本質上是流暢的，這導致我們遵循Oauth2建議的原則構建了多種混合/自定義實現。OpenID-Connect解決了其中的一些問題的關注點，並且是基於Oauth2的相對新的（和成熟的）規范 ）

ASP.NET MVC應用程序的密碼授予–

密碼授予旨在用於資源所有者與客戶端（例如本機應用程序）具有牢固的信任關系的情況下。 對於此用例，建議的授予類型為授權代碼流。

Web API的客戶端憑據–

你是對的。 當應用本身也是資源所有者時，將使用“客戶端憑據”授予類型

Windows服務的授權碼？

由於規格中的上述原因（用戶代理重定向要求等），授權代碼流程不適用於此處。 根據Windows服務的類型，我將使用“客戶端憑據”或“密碼”授予類型

兩種類型都能凝聚嗎？ 如何通過使用身份服務器實現apiKey？

對於您的要求，我不是100％肯定的。 但是，如果您可以在此處發布更多關於要實現的目標的詳細信息和背景。 我很確定Brock / Dominick應該能夠確認。