spring-security-oauth2 authorizedGrantTypes的配置在實踐中意味着什麼？

Question

例如在默認jhipster UAA配置有：

clients.inMemory() .withClient("web_app") .scopes("openid") .autoApprove(true) .authorizedGrantTypes("implicit","refresh_token", "password", "authorization_code") .and() .withClient(jHipsterProperties.getSecurity() .getClientAuthorization().getClientId()) .secret(jHipsterProperties.getSecurity() .getClientAuthorization().getClientSecret()) .scopes("web-app") .autoApprove(true) .authorizedGrantTypes("client_credentials");

那麼什麼是 「authorizedGrantTypes」 的真正含義在實踐中？第一個客戶端「web_app」將具有不同的類型，包括刷新，因此第二個客戶端將能夠生成一個標記爲client_credentials。有什麼不同？

另一個問題，使用「client_credentials」的第二個客戶端身份驗證的目的是什麼？由於這與存儲的真實用戶斷開連接。微服務到微服務通信？如果配置部署在Spring雲（客戶端和祕密硬編碼配置）上以允許通過網關進行任何外部身份驗證，則看起來很糟糕。如何防止這一點？

Answer 1

OAuth 2.0grant types是您的客戶端應用程序可以獲取令牌的不同「方法」。

有一堆articles解釋它better，但這裏是一個總結：

• authorization_code是「經典」的OAuth 2.0流，用戶被要求通過重定向同意。客戶端應用程序被強烈認證，因爲它必須發送其所有憑據（client_id + client_secret + redirect_uri）才能獲得令牌。
• implicit與authorization_code幾乎相同，但對於公共客戶端（網絡應用程序或已安裝/移動應用程序）。從用戶的角度來看，流程幾乎相同，但採用較弱的客戶端身份驗證。 redirect_uri是唯一的安全性，因爲客戶端通過重定向+請求參數接收訪問令牌。
• password是直截了當：客戶端應用程序收集用戶憑據，並換取令牌同時發送用戶憑據（username + password）和自己的憑據（client_id + client_secret）。這種流程將授權與身份驗證混合在一起，只能在沒有其他選擇的情況下使用（即您自己的已安裝/移動應用程序，您不希望用戶在原生應用程序和瀏覽器之間來回切換）。您應該從不允許第三方使用此流程。

在所有這些流程中，用戶都會以這樣或那樣的方式獲得其許可。授予客戶端的令牌只允許訪問單個用戶的數據。

client_credentials授予是不同的，因爲它不涉及用戶。這是對HTTP Basic的替代。
對於每個請求，您的客戶端不會發送用戶名（client_id）+密碼（client_secret），您的客戶端會發送憑證以換取令牌。

它用於服務器到服務器的通信，在那裏你想知道「哪個應用程序正在調用」，通過給它明確的憑據，但你不把它的授權與特定用戶聯繫起來。

一些例子：

• 一個命令行應用程序（批次）或工作進程消耗固定服務。這種應用程序可能一次處理大量的用戶數據，並且不能請求每個用戶的同意。被調用的服務必須知道「誰」正在調用以允許客戶端應用程序訪問任何東西。
• 您的API的第三方/外部客戶想知道未鏈接到用戶數據的信息（例如：使用狀態，配額，結算...）
• 具有特殊權限的第三方/外部客戶可以訪問所有用戶的數據

---

注：在服務業務通信，你應該中繼從外部接收，而不必每個中間應用請求自己的令牌，令牌。