通過OAuth 2.0從受信任的SPA對用戶進行身份驗證？

我有一個自定義的OAuth 2.0身份驗證服務器與我的安全API一起部署。我還有一個單頁應用程序通過nginx部署以靜態內容的形式提供。我現在面臨的問題是如何驗證此SPA的用戶，而沒有通過其代理密碼授權的主動後端 - 我顯然不能將客戶端祕密嵌入到SPA中。通過OAuth 2.0從受信任的SPA對用戶進行身份驗證？

這樣的問題存在哪些解決方案？

我發現資源所有者密碼憑據授權可能正是我正在尋找的。通過使用此功能，我將能夠使用已建立的客戶端ID直接從我的可信SPA發送用戶名和密碼憑證。如果我將此授權限制爲僅對該特定客戶有效並驗證請求的來源，我可以看到這是一個合理的折衷。

我的問題就變成了，我該如何創建這個客戶端和必要的關聯用戶？這並不意味着我的系統中有一些特殊的用戶帳戶與這個關聯的特權客戶端？ OAuth 2.0似乎意味着客戶必須與某種用戶相關聯。我的應用程序部署時是否要爲這些特殊用戶和客戶端對象生成種子？這是安全的嗎？

來源

2017-04-07 DaveStance

你檢查了隱式流程嗎？這是通常用於SPA的人。 –

@JánHalaša，我有。這是我最初的假設，但我相信這仍然需要最終用戶的重定向，這是不正確的？ – DaveStance

是的，首先將用戶轉發到OAuth2服務器，然後返回到您提供的redirectUrl。您在重定向網址的哈希部分中獲得訪問令牌。重定向有問題嗎？ –

我認爲隱式流可以使用得很好。

用戶從SPA重定向到的OAuth2服務器
用戶真實性被驗證
用戶與令牌

對於服務器端API一起重定向回SPA，你需要決定是使用訪問令牌還是使用ID令牌（OpenID Connect - OAuth2擴展）。

如果用戶對API的權限存儲在OAuth2服務器上，SPA可能會要求用戶提供一些將包含在訪問令牌中的權限。這是一個權限授權，如果有更多的應用程序需要不同的權限，它可以很方便。

如果OAuth2服務器不具有權限並且API本身管理它們，則可能更適合使用ID令牌，因爲它們表示調用方的身份，並且可以在每次訪問時都不訪問OAuth2服務器的情況下進行驗證。

API可能不需要具有其client_id，因爲它只接受令牌 - 它不會請求它們 - 它會檢查訪問令牌是否包含用戶調用或驗證ID令牌的操作的權限。

SPA需要有註冊redirect_uri-s的client_id。因爲SPA-s不能保證他們的安全，所以不需要客戶祕密。必須使用HTTPS部署它才能確保傳輸的令牌。

來源

2017-04-11 19:59:58

通過OAuth 2.0從受信任的SPA對用戶進行身份驗證？

回答

相關問題