周末逛简书，看了一篇写的极好的文章，点击大红心点赞，就直接给我跳转到登录界面了，原来点赞是需要登录的。
可是没有我并没有简书账号，一直使用的QQ的集成登录。下面有一排社交登录按钮，我们可以用第三方社交账号登陆即可。点击QQ图标，就给我跳转到了QQ登录授权页面，如下图：
从图片上我们可以看到主要包括两个部分，一个是左边的用户登录，一个是右边告知简书将获取哪些权限。输入QQ账号和密码，点击授权并登录，就成功登录到简书了，并成功获取到了我QQ的账号和昵称，如下图：
无图无真相，咱们看看控制台的网络监控：
如图所示，除了scope参数外，其他四个参数均有传参。
此时你可能唯一对state参数比较迷惑，传递一个state参数，认证服务器会原封不动返回，那还干嘛要传递state参数呢？
我的理解是，简书用一个guid加长版字符串来唯一标识一个授权请求。这样才会正确获取授权服务器返回的授权码。
这里你可能会问了，既然我知道了这些参数，我岂不是可以伪造简书认证请求，修改redirect_uri参数跳转到个人的网站，然后不就可以获取QQ授权？
跟我一样太傻太天真，简书在QQ互联平台申请时肯定已经预留备案了要跳转返回的URL。QQ互联平台在收到简书的授权请求时肯定会验证回调Url的。
redirect_uri、state完全一致。
发送完该请求后，认证服务器验证通过后就会发放令牌，并跳转会简书，其中应该包含以下信息：
这个时候简书还有一件事情要做，就是把用户token写到cookie里，进行用户登录状态的维持。咱们还是打开控制器验证一下。
不用打cookie的歪主意了，肯定是加密了的。
可以尝试下手动把remember_user_token这条cookie删除，保证刷新界面后需要你重新登录简书。
这里你可能又有疑问了，那既然每次进行令牌延期后都会重新返回一个refresh_token，那岂不是我可以使用refresh_token无限延期？
天真如我啊，refresh_token也是有过期时间的。而这个过期时间具体是由认证服务器决定的。
假设简书从QQ互联平台默认获取到的access_token的有效期是1天，refresh_token的有效期为一周。
用户今天使用QQ登录授权后，过了两天再去逛简书，简书发现token失效，立马用refresh_token刷新令牌，默默的完成了授权的延期。
假如用户隔了两周再去逛简书，简书一核对，access_token、refresh_token全都失效，就只能乖乖引导用户到授权页面重新授权，也就是回到OAuth2.0的第一步。
本文以简书通过QQ进行授权登录为例，对OAuth2.0 的授权流程进行了梳理，希望通读此文，对你有所帮助。
如果对OAuth2.0有所了解的话，你应该明白本文其实是对OAuth2.0中授权码模式授权方式的讲解。
如果想了解OAuth2.0其他几种授权方式，建议参考。
阅罢此文，如果您觉得本文不错并有所收获，您可以通过右边的【打赏】按钮进行打赏给予鼓励，或点击【推荐】进行精神赞助，也可【评论】留下您的问题或建议与我交流。
您的支持是我不断创作和分享的不竭动力！
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文链接，否则保留追究法律责任的权利。
周末逛简书，看了一篇写的极好的文章，点击大红心点赞，就直接给我跳转到登录界面了，原来点赞是需要登录的。
可是没有我并没有简书账号，一直使用的QQ的集成登录。下面有一排社交登录按钮，我们可以用第三方社交账号登陆即可。点击QQ图标，就给我跳转到了QQ登录授权页面，如下图：
从图片上我们可以看到主要包括两个部分，一个是左边的用户登录，一个是右边告知简书将获取哪些权限。输入QQ账号和密码，点击授权并登录，就成功登录到简书了，并成功获取到了我QQ的账号和昵称，如下图：
无图无真相，咱们看看控制台的网络监控：
如图所示，除了scope参数外，其他四个参数均有传参。
此时你可能唯一对state参数比较迷惑，传递一个state参数，认证服务器会原封不动返回，那还干嘛要传递state参数呢？
我的理解是，简书用一个guid加长版字符串来唯一标识一个授权请求。这样才会正确获取授权服务器返回的授权码。
这里你可能会问了，既然我知道了这些参数，我岂不是可以伪造简书认证请求，修改redirect_uri参数跳转到个人的网站，然后不就可以获取QQ授权？
跟我一样太傻太天真，简书在QQ互联平台申请时肯定已经预留备案了要跳转返回的URL。QQ互联平台在收到简书的授权请求时肯定会验证回调Url的。
redirect_uri、state完全一致。
发送完该请求后，认证服务器验证通过后就会发放令牌，并跳转会简书，其中应该包含以下信息：
这个时候简书还有一件事情要做，就是把用户token写到cookie里，进行用户登录状态的维持。咱们还是打开控制器验证一下。
不用打cookie的歪主意了，肯定是加密了的。
可以尝试下手动把remember_user_token这条cookie删除，保证刷新界面后需要你重新登录简书。
这里你可能又有疑问了，那既然每次进行令牌延期后都会重新返回一个refresh_token，那岂不是我可以使用refresh_token无限延期？
天真如我啊，refresh_token也是有过期时间的。而这个过期时间具体是由认证服务器决定的。
假设简书从QQ互联平台默认获取到的access_token的有效期是1天，refresh_token的有效期为一周。
用户今天使用QQ登录授权后，过了两天再去逛简书，简书发现token失效，立马用refresh_token刷新令牌，默默的完成了授权的延期。
假如用户隔了两周再去逛简书，简书一核对，access_token、refresh_token全都失效，就只能乖乖引导用户到授权页面重新授权，也就是回到OAuth2.0的第一步。
本文以简书通过QQ进行授权登录为例，对OAuth2.0 的授权流程进行了梳理，希望通读此文，对你有所帮助。
如果对OAuth2.0有所了解的话，你应该明白本文其实是对OAuth2.0中授权码模式授权方式的讲解。
如果想了解OAuth2.0其他几种授权方式，建议参考。
阅罢此文，如果您觉得本文不错并有所收获，您可以通过右边的【打赏】按钮进行打赏给予鼓励，或点击【推荐】进行精神赞助，也可【评论】留下您的问题或建议与我交流。
您的支持是我不断创作和分享的不竭动力！
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文链接，否则保留追究法律责任的权利。
[[[[注]]]] 本文所有代码中的大写字母部分为需要用户自己填写的。
| 申请应用时分配的app_key | ||||||||||||||||||||||||||||||||||
| 授权回调地址，必须和应用注册的地址一致 | ||||||||||||||||||||||||||||||||||
主要用于指定手机授权页的版本，无此参数默认显示pc授权页面
|