oauth2学习笔记
场景
- 服务方不信任用户，所以需要用户提供密码或其他可信凭据
- 服务方不信任第三方，所以需要第三方提供自已交给它的凭据
- 用户部分信任第三方，所以用户愿意把自已在服务方里的某些服务交给第三方使用，但不愿意把自已在服务方的密码交给第三方
举例
- 阮一峰老师的文章点这里
- 我们有个自己的应用，为了方便用户使用，接入微信的第三方认证。于是在微信官方注册一个client_id，当用户使用我们系统时，点击微信登录方式，
- 于是我们的页面带上client_id跳转（重定向）到微信的登录页去，微信拿到client_id识别出我们是在他那注册的应用。
- 微信登录成功之后跳转（重定向）回我们的页面，并带回一个授权码
- 我们拿到授权码后返回给我们的后台服务系统，后台服务系统将client_secret、client_id和授权码发送给微信方，微信方确认我们的用户后返回一个令牌
- 我们的后台处理微信给的令牌后，我们便可以通过令牌获取到我们能在微信获取的信息，比如识别用户是谁
扩展state
- 我们在第一步时可以生成一个state一起发过去，这是因为第二步第三方返回我们页面时，我们并不知道是谁过来的。假设我们有甲乙用户登录到第二步微信方返回授权码给我们的时候，他们交换地址，然后后面的步骤接着走下去，那么就会出现甲拿到了乙的微信信息。
- 攻击者的目标，其实就是要获取微信返回地址，然后诱骗已登录网站甲的受害者点击，从而改变了绑定关系。
- 详细请看这里
扩展自定义第三方登录页面
- 有时候我们的业务不想要第三方的登录页，而是使用我们自己定义的登录页接入第三方（第三方支持的情况）。下面描述一个简单的流程。
- 我们在我们自定义的登录页让用户输入登录信息
- 我们将数据返回给我们后台，后台将数据和client_id交给第三方，第三方确认用户之后返回一个sn串
- 我们前端将这个sn串和client_id跳转（重定向）至第三方，第三方识别sn串和用户后完成第三方自己的登录，再返回授权码跳转（重定向）至我们的页面，然后执行上面举例中的3、4步
