oauth2 流程疑问

2021-09-14 15:49:42 +08:00
 flycloud

大家好,最近在看了 oauth2 的流程。在第一步确认授权,从开放平台获取到 code 后,客户端会被重定向到一个之前设置好的 redirect_uri,这个一般是我们自己应用的后端服务地址,然后由这个后端服务带上 app_id 、app_secret 和 code 向开放平台请求获取 token 。自己的后端服务得到 token 后,其实就已经完成了登录流程,这期间 token 对客户端是不可见的。

问题 1:是否需要通过重定向的请求回复客户端 token 、openid ?

问题 2:后端服务从开放平台获取到了 token 就完成了登录,那如何收集客户端的设备、版本信息呢?难道是将 token 、openid 告诉客户端,通过另外下一个请求来上传客户端信息?

oauth2 流程图:

1745 次点击
所在节点    程序员
16 条回复
keller
2021-09-14 15:53:07 +08:00
*这个一般是我们自己应用的后端服务地址*
也可以是前端的地址拿到 code 后请求后段获取 token 呀????
flycloud
2021-09-14 16:01:38 +08:00
@keller 没太明白,如果是 app 应用呢?在开放平台确认授权后,code 返回到 app,然后由 app 向自己的后端发请求获取 token ?
Saxton
2021-09-14 16:01:43 +08:00
前端分离的项目基本是前端先拿到 code 在请求给后端,这个时候你就可以连同 code 带上设备信息了
不一定要让后端去接收这个回调,反正后端只是负责消费 code 的行为就好了,至于你怎么拿到这个 code 是你的事了
Saxton
2021-09-14 16:03:29 +08:00
@flycloud 是的 app 基本都是这样, 都是拿到 code 在由 app 去发起一个 code 消费,这个时候你就可以带上你的设备信息以及信息了,你如果会抓包的话,可以去抓抓京东或者一些 APP 的 oauth2 登录包,建议去抓京东看看,全是明文的看得明白
flycloud
2021-09-14 16:04:29 +08:00
@Saxton 意思就是在开放平台填的 redirect_uri 可以不是后端的地址,直接把 code 给前端,然后前端主动从自己的后端获取 token,而不是通过重定向?
flycloud
2021-09-14 16:05:45 +08:00
@Saxton #4 明白啦,感谢
flycloud
2021-09-14 16:09:24 +08:00
@Saxton 还有个疑问是 token 和 openid 是不是要告诉前端才行,后续请求都会带上 token,token 也存储在自己的后端进行验证,是这样做的吗?
Saxton
2021-09-14 16:12:38 +08:00
@flycloud 后端消费完 code 不就知道哪个用户了嘛,生成 token 和 openid 给到前端就行了,请求本身就是前端发起的,前端自然能接受到后端返回的,储存到 cookie 或者哪里都行 然后所有需要登录的请求带上 token,只是把账号密码转变成了 code,思路其实都一个样
flycloud
2021-09-14 16:25:17 +08:00
@Saxton #8 这下清晰了,谢谢。之前在微信平台看到这段话,感觉有点懵逼:

“access_token 为用户授权第三方应用发起接口调用的凭证(相当于用户登录态),存储在客户端,可能出现恶意获取 access_token 后导致的用户数据泄漏、用户微信相关接口功能被恶意发起等行为”
Saxton
2021-09-14 16:27:11 +08:00
@flycloud code 交换出 openid 和 access_token 这个 access_token 是针对于你后端和微信后端之前的数据通讯的 不是你后端和前端的,所以没有必要下发给前端是正常的,access_token 是用来后端对微信后端 API 发起时携带的,比如我需要获取用户的微信信息,不要理解错了
Saxton
2021-09-14 16:28:22 +08:00
@flycloud 因为 code 是临时并且一次性的,消费完就没了,那下次我要调第三方接口的时候总不能又走一遍 oauth2 吧 那这个 access_token 就是拿来识别的
flycloud
2021-09-14 16:33:44 +08:00
@Saxton #10 哦哦哦,后端通过 code 交换出 openid 和 access_token 后,再自己生成一个 token 给前端用,同时存储 token 、openid 、access_token,后续如果需要 refresh token,也是由后端来完成的。这样对吧?
Saxton
2021-09-14 16:36:26 +08:00
@flycloud 肯定是由你自己的后端完成,微信给你的是他后端的,其实你对接微信登录真正用到的也就 openid 就足以,你自己的用户绑定到这个 openid 走登录流程拿到这个 openid 不就知道谁是谁了吗,剩下的就和你通过账号密码登录一样了,都是生成 token 下发给前端
flycloud
2021-09-14 16:39:49 +08:00
@Saxton #13 嗯嗯,那就是如果不需要从微信获取用户信息的话,只用维护自己的 token 就行了。自己的 token 过期了,就再走一遍授权流程重新登录嘛?
Saxton
2021-09-14 16:45:09 +08:00
@flycloud 是的,维护自己的 token 就行了,除非你有业务逻辑需要用到微信 access_token,那你就必须维护 access_token
junjie2025
2021-09-18 16:35:13 +08:00
你给的图是授权码模式,所以你说的客户端,是 OAuth2 中的 Web 浏览器,对应到图中的 User,你说的后端服务是 OAuth2 中的客户端,对应到图中的 Client 。你说的 token 是 OAuth2 中的 AccessToken

1.AccessToken 是不可以告诉浏览器的,因为任何人拿到你的 AccessToken 都可以直接从资源服务器上获取数据(针对 Bearer 令牌)。
2.你是要收集浏览器的设备、版本信息么,如果是的话应该由很多方案吧。

如果你说的是原生应用,或纯粹的浏览器应用(不包含后台),貌似最推荐的模式是隐式授权模式。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/801784

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX