0
此問題更像是體系結構問題。我想知道下面的設置是否有意義。資源所有者授權流程的Identity Server使用案例
- 客戶端：用戶的瀏覽器
- Web服務器：服務於網頁API的Web應用程序的服務器。
- Identity Server的
當客戶端發送的登錄到Web服務器的請求，Web服務器接收請求，並將其發送到Identity服務器通過資源所有者授權類型得到一個訪問令牌。
當客戶端發送資源請求時，它使用上一步中的訪問令牌訪問Web服務器，並且Web服務器每次需要在提供資源之前驗證與Identity Server的請求。
不過，我認爲這種架構可能有一些問題，如
Web服務器不能確定，如果客戶是即使在SSL連接的信任客戶端。客戶端總是可以獲取訪問令牌並將請求發送到Web服務器。但是，我覺得這個問題也存在於其他授權類型中。 我想只要用戶不能更改授予範圍或其他人攔截令牌（在SSL連接下），它應該沒問題。
有什麼想法？謝謝 ！
好吧，我的問題是更喜歡當Web服務器和IDSrv來自同一政黨都是，什麼是做3條腿的驗證，而不是2好處 - 有腿？ – maxisam
如果沒有瀏覽器流程，您將無法在多個應用程序之間獲得SSO。 – leastprivilege
好點。因此，如果我讓用戶將用戶名/密碼發送到Web srv，Web srv將它發送到IDSrv以獲取訪問令牌（資源所有者流）。一旦Web srv獲取它，將其發送回用戶。它仍然具有SSO，並且用戶不會直接與資源所有者流交談IDSrv。它工作嗎？因爲其他流程需要URI重定向，這對於使用現有的本機應用程序來說並不理想。 – maxisam