且构网

分享程序员开发的那些事...
且构网 - 分享程序员编程开发的那些事

Google Oauth-后端/前端登录用户的位置

更新时间:2023-12-02 11:49:34

使用Google OAuth和登录用户有什么区别 在应用程序的前端,然后在 应用程序的后端?

因此,为了澄清所有阅读此内容的人,在应用程序后端登录用户是对服务器进行OAuth表示的另一种方式,而在应用程序前端对用户进行登录是针对JavaScript浏览器应用程序(如React)的OAuth的另一种方式. /p>

通过OAuth针对服务器和浏览器登录用户会导致一个令牌",服务器/浏览器可以使用该令牌代表用户发出请求.我们要求用户通过外部服务提供商(例如,电子邮件地址,某种形式的标识)向我们提供访问其信息的权限,并且该令牌将位于该令牌内以及一些可能的权限,这些权限允许我们代表该用户采取措施用户.

一种或另一种方法是否有优势,这是大多数 常见并且有任何规则"吗?

当我们有一个需要在未登录时访问用户数据的应用程序时,通常会使用服务器端OAuth.因此,如果您尝试构建一个需要每十分钟访问一次用户电子邮件的应用程序,并且可能将其删除代表用户发送电子邮件,无论他们是否登录到我们的应用程序,您都希望能够每10分钟访问一次他们的电子邮件帐户.因此,对于此用例,我们希望将Oauth用于服务器.

否则,如果我们不尝试代表用户执行任何操作(除了将他们登录到我们的应用中),那么我们就可以使用针对浏览器的OAuth.

What is the difference between using Google OAuth and signing in users at the frontend of the application, and signing in users at the backend side of the application?

Example: Signing in users and getting the ID and a auth object in React or letting Node/Express handle everything, the prosess, redirecting and store it in a database.

Is there any advantages for one or the other methods, which are most common and are there any "rules"?

What is the difference between using Google OAuth and signing in users at the frontend of the application, and signing in users at the backend side of the application?

So to clarify to everyone reading this, signing in users at the backend side of the application is another way of saying OAuth for servers and signing in users at the frontend of the application is OAuth for JavaScript browser applications such as React.

Signing in users via OAuth for servers and browsers results in a 'token' that a server/browser can use to make requests on behalf of the user. We are asking the user to provide us access to their information via an outside service provider such as an email address, identification of some sort and it will be inside that token as well as some possible permissions that allow us to take actions on behalf of that user.

Is there any advantages for one or the other methods, which are most common and are there any "rules"?

Server-side OAuth is usually used when we have an app that needs to access user data when they are not logged in. So if you are attempting to build an application that needs to access the users email every ten minutes and possibly delete emails on the users' behalf, you would want to be able to access their email account every 10 minutes regardless of whether they are logged into our application. So for this use case we want to make use of Oauth for server.

Otherwise, if we are not trying to do anything on behalf of the user except sign them into our app, then we can just go with OAuth for browser.