作者回复: 你好，细节可以参考： 1. 课程ppt的63页的CSRF交互流程图，https://github.com/spring2go/oauth2lab/tree/master/ppt 2. RFC6749的10.12的Cross-Site Request Forgery，https://tools.ietf.org/html/rfc6749 这个案例演示授权请求时候，如果不使用state参数，那么可能被黑客利用，简化步骤（假定黑客和普通用户都是某个客户应用Web App的用户）： 1，黑客去授权服务器登录，授权并获取授权码， 2，黑客使用工具截获跳转请求和授权码（本来这个请求会发到客户应用Client App，然后客户应用再去授权服务器换令牌）， 3，黑客伪造带授权码（和黑客账户绑定）的URL，并通过手段诱使普通用户点击这个URL 4，普通用户点击这个URL（相当于跳转到客户应用Client App，接续之前黑客发起的令牌请求），获取了令牌（假定授权码还没有过期），但是这个令牌其实和黑客账户关联 5，普通用户操作了受保护的资源，例如保存了自己的银行账户信息，但其实这个账户信息可以被黑客看见，因为操作受保护资源使用了黑客的令牌，相关资源也和黑客关联。 如果使用state，这个state就和用户的认证状态关联，有唯一性，时效性，且只能使用一次。如果使用了Spring Security OAuth2开发的客户应用Web App，它就支持state校验和传递，黑客使用的state只和黑客认证关联，他无法伪造和普通用户认证相关联的state。

作者回复: 不能写死，客用应用随机生成并记住（关联当前用户会话），再发起授权码请求，响应回来再比对，对得上表示这个响应是针对同一用户的。

作者回复: 黑客的state是和黑客在客户应用(Client App)上的会话Session相绑定的，给正常用户用的话，正常用户在客户应用的Session会和这个state不匹配，会被客户应用拒绝。Spring Security OAuth2开发的客户应用支持state，并且会将state和session绑定和进行校验。参考：https://tools.ietf.org/html/rfc6749#section-10.12

作者回复: 不一样，state具有4个特性：1.随机不可预测，2.关联当前用户会话，3.每用户每次请求都唯一，4.时效性，一旦被用则立即失效

作者回复: 黑客可以邮件，聊天消息，或伪造站点等形式诱使正常用户点击伪造url，点击后可获取访问令牌（因为有正确授权码），但是这个令牌其实是和黑客关联的，后面如果正常用户做一些交易动作，那么这些动作其实关联到黑客