Google Oauth-后端/前端登錄用戶的位置

Question

使用Google OAuth和在應用程序前端登錄用戶與在應用程序后端登錄用戶之間有什么區別？

示例：登錄用戶並在React中獲取ID和auth對象，或者讓Node / Express處理所有內容，過程，重定向並將其存儲在數據庫中。

一種或另一種方法是否具有最普遍的優勢，並且有任何“規則”？

Answer 1

這兩件事是非常不同的。 在不知道要完成的操作的具體細節的情況下，您應該了解一般規則，即僅前端身份驗證和授權會使您極度脆弱。

如果某人精通JavaScript，或者正在使用編輯插件，或者有上百萬種不同的東西，那么他們可以繞過很多前端授權。 或者他們可以只看看您的應用對后端的調用，然后模擬諸如Postman之類的調用，完全繞開您的Web前端。

如果您沒有保護自己的后端，那么您就沒有安全感。 通常，系統會同時執行這兩種操作。

Answer 2

這只是將用戶注冊到我們網站的一種不同方式。

使用OAuth在前端登錄用戶非常方便，因為它使我們的用戶不必瀏覽我們網站中無聊的表格。 使用OAuth只需在我們網站上注冊用戶一鍵之遙。 有益於客戶和開發人員。只需單擊一個按鈕，提供者（google，facebook）就會為我們提供有關客戶的一般信息。

在后端登錄用戶是注冊客戶的傳統方式。 在這里，我們強迫客戶在我們的網站上填寫表格（如果表格較長，可能會很痛苦），所有填寫的數據都存儲在我們的數據庫中。

因此，它們都是將客戶注冊到我們網站的不同方式。 兩者都經常使用。 這取決於用例和需求。 如果您想通過一鍵注冊吸引更多客戶，可以使用Oauth。

Answer 3

使用Google OAuth和在應用程序前端登錄用戶與在應用程序后端登錄用戶之間有什么區別？

因此，向所有閱讀本文的人澄清一下，在應用程序后端登錄用戶是對服務器進行OAuth表示的另一種方式，而在應用程序前端對用戶進行登錄是針對JavaScript瀏覽器應用程序（如React）的OAuth。

通過OAuth針對服務器和瀏覽器登錄用戶會導致一個“令牌”，服務器/瀏覽器可以使用該令牌代表用戶發出請求。 我們要求用戶通過外部服務提供商向我們提供訪問其信息的權限，例如電子郵件地址，某種形式的標識，並且該標識將位於該令牌內以及一些可能的權限，這些權限允許我們代表該用戶采取措施用戶。

一種或另一種方法是否具有最普遍的優勢，並且有任何“規則”？

當我們有一個需要在未登錄時訪問用戶數據的應用程序時，通常會使用服務器端OAuth。因此，如果您試圖構建一個需要每十分鍾訪問一次用戶電子郵件的應用程序，並且可能會刪除用戶端上的電子郵件代表用戶，無論他們是否登錄到我們的應用程序，您都希望能夠每10分鍾訪問一次他們的電子郵件帳戶。 因此，對於此用例，我們要對服務器使用Oauth。

否則，如果我們除了代表他們登錄我們的應用程序外不嘗試代表用戶做任何事情，那么我們可以使用瀏覽器的OAuth。