作者回复: 为了安全性的考虑,是不可以让“token一个更长的有效期”存在的。
作者回复: 感谢 约书亚 指正 我翻看了 之前的回复 做了修改。
1、:若access_token未超时,那么进行refresh_token有两种方式,(1)不会改变access_token,但超时时间会刷新,相当于续期access_token(2)更新access_token的值,我们建议【统一更新access_token的值】。
2、延期access_token并不是一个最好的方式,尽管有的开放平台是这么做的。
3、在我们这节课中,我们是提到了这点,本文中的描述是:【用来通过系统重新请求生成一个新的访问令牌】
而且咱们这节课的建议也是更换一个新的访问令牌。
4、“因为我感觉无限续期会增加access被破解的风险”
刷新令牌也有有效期。
作者回复: 对应的权限 都是同一个权限,这里用rscope是受保护资源服务再次确认的权限,r是replay。
作者回复: SCOPE的权限范围非常重要,OAuth 2.0 本着【最小权限范围】原则,来支持用户对第三方软件授权。比如小兔打单软件,他的主要“行当”就是帮助小明打印订单,那么它的权限范围就是调用跟订单打印相关的API,比如单条查询订单API、批量查询订单API,那么查询小明店铺其它的API就要受限,在小兔打单软件申请成为开放平台的应用的时候就要做一次权限范围的选择,另外,当小明给小兔进行授权的时候,也会让小明去选择并确认,总之就是不要让小兔打单软件有超过其正常权限的范围,来充分保护小明店铺的数据。后面的课程,我们还会详细讲解关于SCOPE的种类和用法。
作者回复: 1.刷新令牌和授权码完全两个东西
2.刷新令牌换回来的访问令牌一定是变的
3.不可以,有2所以3不成立
对于第2点,可能是马成看了上节课的留言回复,当时有不准确的描述,我已修改,最好的方案是:更新访问令牌的值,这也是咱们这节课给出的建议【用来通过系统重新请求生成一个新的访问令牌】。
“若access_token未超时,那么进行refresh_token有两种方式,(1)不改变access_token,但超时时间会刷新,相当于续期access_token(2)更新access_token的值,我们建议【统一更新access_token的值】”
作者回复: 当刷新令牌被使用过,授权服务可以自行决定是否颁发新的刷新令牌来替换旧的,我们的建议是生成新的。
refresh_token 的有效期具体多长时间,同样在OAuth 2.0 规范里面并没有给出确定值,一般比 access_token 的有效期长1-7天。
作者回复: 是的,当刷新令牌也过期了,只能重新登录再授权。
作者回复: 第三方软件需要在平台一侧提前注册好app_id,同时平台会为三方软生成app_secret。
作者回复: 如果是用微信登录这样的方式,我们讲它背后实际上是走了一次OAuth2.0的流程,第三方软件会拿到一个用户的标识,可以是类似”userid“的东西,这个第三方软件要存下来,用以判断当前的用户。如果是在这种方式下,授权服务就是指的微信内部的一个服务了,这个”userid“生成的粒度就是app粒度的,也就是不同的应用同一个用户会有不同的”userid“
作者回复: 用户主动登录是授权的前提,因为授权的这个动作发生在平台一方,既然发生在平台一方,用户登录后,平台一方肯定是能获取到当前登录用户的信息,那么当授权服务去生成token的时候,就能够知道是哪个用户为哪个第三方软件进行了授权。严格意义上只有这一个给第三方软件生成的token。
作者回复: OAuth 2.0 内部并没有规定我们令牌使用什么样的算法生成,我们可以是一个随机数,只要符合唯一性、不可猜测性就可以。在使用刷新令牌的时候,也是需要应用传递它的app_id和app_sercet的。
作者回复: 需要再次校验的。
作者回复: OAuth 2.0 最初的场景就是发生在Web环境下,你可以看咱们的02课程里面,我们有提到。
作者回复: 可以直接判断,也可以将其作为【因子】加入到签名算法中。
作者回复: 小兔打单软件应用对应的研发人员需要事先在授权服务一侧注册好,生成app_id和app_secret等信息,注册的时候就要申请一次权限,比如你这个应用是什么类型的,能访问哪些API,注册的时候没有小明的参与。
作者回复: 在实际生产环境中,这个用户ID是不需要传递的也不可能被传递,因为OAuth 2.0的目的之一就是不让第三方软件接触到用户ID。
第一次跟用户ID有关系的时候就是在用户给第三方软件授权的时候,这个时候如果用户没有登录就会先登录再授权,这一切都是发生在平台的一方,所以平台能够拿到用户的ID,继而在给第三方软件生成访问令牌的时候,就可以让这个访问令牌access_token的值跟第三方软件的app_id和用户ID做一个映射关系,同理refresh_token的生成也是一样的,并且refresh_token和access_token是一起生成并返回给第三方软件。
我们在代码中为了演示refresh_token和access_token的生成都是在app_id和用户这个粒度的,是“特意”固定写死了一个USERTEST值。
作者回复: 1、刷新令牌也有有效期
2、code在前端传输,还有在后端传输的app_secret