作者回复: 是的
作者回复: sessionid和access_token是两个完全不同的事物,sessionid是会话,access_token不能等同于会话,它是第三方软件代表用户访问数据的凭证。
作者回复: 1、也是按照第三方应用提前在平台上申请好的appid来判断验证。 2、是的。 3、必须的。 4、PKCE后面课程有介绍,这是一个增补协议,并不是授权许可类型之一。
作者回复: 隐式许可类型的初衷是为了让嵌入到浏览器内应用也能够使用上OAuth2.0的方案,那么在”基础设施“都欠缺的情况下,比如就是没有或者不用服务端这样的时候,也能有一个选择。一般这样的应用使用时长都会很短暂,用完即走。
作者回复: 登录和授权是两个通路的事情,任何授权都是在用户登录之后进行的。 用户的用户名和密码是来进行登陆的,appID和秘钥是用来换取访问令牌的。 授权的本质是令牌,令牌是怎么换来的呢,是用户登录之后的授权,那生成令牌的时候是怎么跟用户的登录关联上的呢,因为授权和登录的后台处理都是”一家“的。 并不是说后端服务绕一圈再去登录,而且生产中登录和授权本来也是有分别的系统来进行处理。
作者回复: 感谢支持
作者回复: 在07我们讲到了不需要浏览器参与使用授权码的场景。
作者回复: 你说的可以称为借助了OAuth的理念,并不是严格意义上的授权。另外用户登录跟授权是两个不同的事情。
作者回复: 无论哪种许可方式都会生成access_token,在生成access_token的时候,对应的权限也都在用户授权的那一刻分配好了,要么是用户显式的在页面上选择了授权的权限内容,要么是后台默认采用了事先平台分配给应用的权限内容。
作者回复: 如果使用了微信登录就走了OAuth2.0流程,自身的登录没有。