Fullstack系统中的auth0流
我有一个反应前端和golang后端。我正在尝试将AUTH0合并用于用户身份验证/授权。我对流程的外观有些困惑，尤其是对OAuth回调的位置。例如：
- 用户单击按钮用户登录
- 用户被重定向到授权服务器（例如Google），在该
- 服务器中，请调用回调URL中的用户登录，并取决于我给出的2件事可能发生的情况：
- 如果我向前端提供了回调，那么前端是否会发出exkange（获取访问/刷新），然后致电我的后端，以便我更新我的新用户的DB表？
- 如果我为后端提供了回调，那么我的后端会进行令牌交换（获取访问/刷新），请为新用户保存适当的用户表，并以某种方式（不确定如何，重定向？）通知关于成功登录的UI并通过访问令牌
- 现在UI可以使用访问令牌在我的后端访问给定用户的受保护资源，
我真的很困惑点3.1 和3.2我找不到任何讨论此事的文章，这让我认为我已经错了……这通常是如何工作的？
I've got a react front end and a golang backend. I'm trying to incorporate Auth0 for user authentication/authorization. I'm a bit confused to how the flow is supposed to look like especially given to where the oauth callback should be. For instance:
- User clicks login in button
- User is redirected to the authorization server (say of google) where user logs in
- The callback url is called and depending on what I've given 2 things can happen:
- If I've provided a callback to my frontend, then the frontend does the token exhange (to obtain access/refresh) and then calls my backend so I update my db tables w/ my new user?
- If I've provided a callback to my backend, then my backend does the token exchange (to obtain access/refreshToken), saves the appropriate user tables for the new user and somehow (not sure how, redirect??) notifies the UI about the successful login and passes the access token
- Now the UI can use the access token to access protected resources on my backend for the given user
I'm really confused about points 3.1 and 3.2 and I cannot find any articles discussing this which makes me think I've got it all wrong... How does this usually work?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
授权服务器将您重定向到您的页面，这将在浏览器中发生。假设它将您将您重定向到
https://myapp.example.com/callback。现在，实际上，您的前端还是后端都可以处理此页面都没关系。由于处理重定向的是浏览器，因此您可以随时通过向浏览器发送响应来响应用户。这是可能的情况。
前端应用程序将获取获取访问令牌所需的授权代码（它将从重定向URI的URL参数读取）。现在，该应用程序可以做两件事：
它可以直接调用授权服务器并交换授权代码以访问访问令牌。这将意味着您正在与公共OAuth客户端打交道（没有秘密），您应该实现 PKCE 为您更好地保护您的应用程序。这也意味着您的前端必须处理令牌本身 - 例如，如果要在页面刷新过程中保留令牌，则必须将其保存在本地存储中等。
。
它可以致电您的后端并发送授权那里的代码。您的后端将处理令牌的代码交换。这意味着您可以拥有一个机密的OAuth客户端并使用秘密。如果需要，后端可以将令牌保存在DB中，并与您的前端建立基于cookie的会话。这意味着所有需要访问令牌的API都必须通过后端。后端还可以使用访问令牌做出响应，以便前端可以直接调用API，但是您必须再次照顾在前部处理令牌。
在这种情况下，
https://myapp.example.com/callback由后端处理。您将授权代码交换为访问令牌。同样，客户可以有一个秘密。然后，您可以将令牌保存在DB中并建立基于Cookie的会话。现在，前端可以通过后端调用API，后端将能够将访问令牌附加到API调用上。另一个解决方案是将后端响应并重定向到前端应用程序，并在重定向URL中发送访问令牌。然后，前端应用程序将能够使用该令牌（因此，这有点像前端应用程序的隐式流程）。您必须小心地满足一些安全性最佳实践，例如，将令牌发送到重定向URI的片段中，而不是作为参数。如您所见，这可能会在许多方面处理。我的建议是选择只有后端获取令牌并保存它们的任何选项，而前端使用基于cookie的会话。这使代币远离浏览器，目前被视为最佳安全实践。 （您可以在我们在Curity上发布的白皮书中阅读有关当前水疗安全性的更多信息： https://curity.io/resources/documents/single-page-application-security-whitepaper ）
The Authorization Server redirects you to your page, which will happen in a browser. Let's say it will redirect you to
https://myapp.example.com/callback. Now, in fact, it doesn't matter whether your frontend or backend will handle this page. As it's the browser that handled the redirect, you can always respond to the user by sending back a response to the browser.Here are the possible scenarios.
The frontend app will get the authorization code that's needed to get the access token (it will read it from the URL params of the redirect URI). Now, the app can make two things:
it can call the Authorization Server directly and exchange the authorization code for an access token. This will mean that you're dealing with a public OAuth client (no secret is used) and you should implement PKCE for better protection of your app. This also means that your frontend will have to handle the tokens itself - e.g. if you want to keep the token during page refresh you will have to save it in the local storage, etc.
it can call your backend and send the authorization code there. Your backend will handle the exchange of code for a token. This means that you can have a confidential OAuth client and use a secret. The backend can save the token in a DB if needed and establish a cookie-based session with your frontend. This means that all calls to the API where the access token is needed will have to go through the backend. The backend can also respond with the access token so that the frontend is able to call APIs directly, but then again you have to take care of handling the token in the front.
In this scenario,
https://myapp.example.com/callbackis handled by the backend. You exchange the authorization code for an access token. Again the client can have a secret. You can then save the token in a DB and establish a cookie-based session. The frontend can now call the APIs through the backend and the backend will be able to attach the access token to the API calls. Another solution is to have the backend respond with a redirect to the frontend app and send the access token in the redirect URL. Then the frontend app will be able to use that token (so this would work a bit like the implicit flow for the frontend app). You have to be careful there to meet some security best practices, e.g. send the token in the fragment part of the redirect URI, not as a parameter.As you can see, this may be dealt with in many ways. My recommendation is to choose any option where only the backend gets the tokens and saves them and the frontend uses a cookie-based session. This keeps the tokens out of the browser and is currently considered best security practice. (You can read more about the current state of SPA security in a whitepaper we've published at Curity: https://curity.io/resources/documents/single-page-application-security-whitepaper)