前言

目前，很多的系统在登录的时候都支持通过第三方账号登录，如通过微信，qq，微博扫描登录。这种一般都是通过OAuth2.0搭建完成的。

有一个问题需要思考：通过第三方应用登录的过程是否存在一些安全问题？

本篇文章就来看看OAuth2.0的登录原理以及可能存在的安全问题。

OAuth2.0登录原理

Oauth2.0具有多种授权许可机制协议：授权码许可机制、客户端凭据机制、资源拥有者凭据机制（密码模式）和隐式许可机制。

在了解授权许可机制协议之前，我们得需要了解在OAuth 2.0 的体系里面有 4 种角色，按照官方的称呼它们分别是资源拥有者、客户端、授权服务和受保护资源。

资源拥有者（可以指拥有资源的用户）

客户端（可以理解为第三方系统/软件）

授权服务（权限校验和授权系统(认证服务中心)）

受保护资源（用户在系统上所具有的资源/或者能够访问的资源）

授权码许可机制

授权码许可机制的参与者：资源拥有者、客户端、授权服务、受保护资源

授权码模式这种场景下的授权，第三方软件可以通过拿到资源拥有者授权后的授权码，以及注册时的 client_id 和 client_secret 来换回访问令牌 token 的值。

时序图

下面以一个网站来看一下具体流程

1）打开网站，选择使用微信登录页面

发送了下面的请求

每个参数的含义如下

• appid：客户端应用程序的唯一标识符的强制参数，此值是在客户端应用程序向OAuth服务注册时生成的。此值唯一，表示来自于那个客户端。

用微信扫描登录时需要再微信开放平台（https://open.weixin.qq.com/）进行注册，注册完成以后可以拿到AppID和AppSecret两个。

• redirect_uri：向客户端应用程序发送授权代码时用户浏览器应重定向到的URI，这也被称为"回调URI"或回调端点"。在微信开放平台填写。
• response_type：确定客户端应用程序期望的响应类型以及它想要启动的流，对于授权代码授予类型，值应为代码
• scope：用于指定客户端应用程序要访问用户数据的哪个子集，这些可能是由OAuth提供程序设置的自定义作用域，也可能是由OpenIDConnect规范定义的标准化作用域
• state：用于存储与客户端应用程序上的当前会话绑定的唯一、不可更改的值，OAuth服务应该在响应中返回这个确切的值以及授权代码，通过确保对其/callback端点的请求来自发起OAuth流的同一个人，此参数可作为客户端应用程序的CSRF令牌形式

这里面可能存在的问题：

• 没有state参数，可能造成什么危害
• redirect_uri是否可以伪造

2）跳转到授权页面，用户手机上扫描二维码

3）手机上确认以后，会返回一个授权码（问题：扫描后看是否需要人工确认）

返回授权码

4）返回授权码以后，前端携带这个授权码到后端，后端就可以与微信端进行交互获取运行的数据

资源拥有者凭据机制（密码模