IdentityServer3 - OAuth流程，不同的方法

我已經構建了一個基本上是REST Web API的應用程序。我想給其他開發者代表用戶調用這些API的機會。我決定繼續進行OAuth身份驗證，將身份驗證服務基於IdentityServer3。現在我已經成功地爲使用授權流程的第三方客戶端生成訪問令牌。IdentityServer3 - OAuth流程，不同的方法

什麼是不說服我是如何處理我的SPA，目前只使用基於cookie的身份驗證（+防僞造令牌）調用我的Web API。這個應用程序用JavaScript寫成，基於Backbone。實質上，它所做的只是調用我的Web API並呈現結果。我對不同的資助流程感到困惑，我不想製造安全漏洞。

解決方案，我想：

直接通過JavaScript生成令牌。我應該使用哪種流程？如何處理令牌刷新？
從後端服務器應用程序生成令牌並將生成的令牌傳回給SPA（顯然是通過SSL通道）。這是否安全？如果是，我應該使用哪種流程（我會說授權碼流）？如何處理令牌刷新？

你會如何處理這個問題？

感謝，

馬爾科

來源

2016-04-22 Marconline

下面是進入的概況的物品，其流動適合哪一種情景：https://leastprivilege.com/2016/01/17/which-openid-connectoauth-2-o-flow-is-the-right-one/

來源

2016-04-22 13:15:29

謝謝！我已經偶然發現了這篇偉大的文章。如果我理解正確，正確的用法是Implict Flow，讓我的Javascript SPA直接處理這個訪問令牌。現在的問題是：讓「瀏覽器」客戶端直接處理令牌是不是「不安全」？謝謝。 – Marconline

取決於API。但是如果你需要JS的調用，那麼你需要給JS一個令牌。也許不同的設計是讓JS調用第一層API，然後調用第二層API。當然，第二個API需要自己的訪問令牌，這是您要解決的下一個問題。 –

好的，謝謝。聽起來像隱式流是正確的解決方案。我不會創建第二層API。謝謝 – Marconline

IdentityServer3 - OAuth流程，不同的方法

回答

相關問題