感谢老师， 从开始学习到现在，被老师纠正了思想，OAuth2.0的核心授权协议，而不是身份认证协议。面粉和面包的关系，感谢老师。安全那块 对RSCF 和XSS的理解还没到位，是自身对这块接触不多，不熟悉。在接下来的时间，多熟悉。

安全无小事！！！ 防止CSRF攻击--授权码附加STATE参数； 防止XSS攻击--服务端对非法信息转义过滤+客户端Cookie设置httponly； 防止令牌劫持--服务端启用HTTPS避免传输层泄漏+跟踪客户端登录设备信息； 防止水平越权--代码中增加“数据归属”逻辑判断。

如何校验status的值

哈哈，我见过某互联网公司的APP，就把是把微信的appId，appSecret打包在APP里。然后以一种你想不到的方式来获取access_token：APP用授权码code+appId+appSecret，先请求自已的Server端，Server端把请求转发给微信Server，拿到access_token，再返回给APP。后续与微信Server的交互都是：APP带着access_token先请求自己的Server端，然后自己的Server端把请求转发给微信Server，再把结果返回给APP。。。

为了防范CSRF攻击： 1. 重要的操作尽量使用POST请求(依旧还是有风险) 2. 在条件允许的情况下，尽量引入第三方的验证码，智能的验证码破解成本高甚至几乎无法破解 3. 在请求头中加入referer字段 为了防范XSS攻击 1.对输入进行过滤、对输出进行转义 为了防范水平越权 1. 服务端一定要校验数据的归属 为了防范授权码失窃 1. 授权服务一定要对重定向URI进行完整性校验 2. 授权码只能使用一次，使用完毕立马失效 3. 授权服务一定要对appId进行校验

老师你好，我始终有一个盲点没想通， OIDC场景下： 1 受保护的资源服务，要如何去鉴权？ 2 我猜是在认证服务器中对access token做非对称加密处理，不知道想的对不对？ 3 如果受保护资源服务器，使用非对称或者对称加密去和认证中心去鉴权，那么密钥在什么时候进行传输比较合适？

OAuth 2.0 是一个授权协议，它通过访问令牌来表示这种授权。第三软件拿到访问令牌之后，就可以使用访问令牌来代表用户去访问用户的数据了。所以，我们说授权的核心就是获取访问令牌和使用访问令牌。OAuth 2.0 是一个安全协议，但是如果你使用不当，它并不能保证一定是安全的。如果你不按照 OAuth 2.0 规范中的建议来实施，就会有安全风险。比如，你没有遵循授权服务中的授权码只能使用一次、第三方软件的重定向 URL 要精确匹配等建议。安全防护的过程一直都是“魔高一尺道高一丈”，相互攀升的过程。因此，在使用 OAuth 2.0 的过程中，第三方软件和平台方都要有足够的安全意识，来把“安全的墙”筑得更高。

思考题，1 熟悉平台方的说明文档；2 掌握网络安全的基础知识；3 定期关注网络安全的最新动态。

按照协议来开发，还有提供一个监控系统监控，时刻注意，纠正