方便的背后是不是总要付出代价？浅谈oAuth 2

方便的背后是不是总要付出代价？浅谈oAuth 2

这一期呢，我们说一下oAuth 2。

先说一个真实的案例。相信你肯定碰到过。你在登录一个应用Test的时候, 有可能让你选择登录方式，可以让你用谷歌账号登录，也可以用脸书账号登录，也可以用微信账号登录。

假设你选中其中一个如微信进行登录的话，会显示一个验证信息的页面，让你同意获取你的基本信息。

如果你点同意，那么你的个人基本信息就被这个应用所访问。

这是一个很典型的OAuth 2的使用案例。

下面说一下oAuth 2里面的角色。一个是用户，一个是应用，另外一个是应用程序接口。

在上面的例子装，用户就是你自己，应用那就是你使用的那个Test应用， 应用程序接口就是微信的信息接口。

上面的过程描述起来相当简单，就是你的这个test应用，从微信获取了你自己的个人信息。那么Test应用怎么会获取到我的个人信息的呢？会不会用我的用户名和密码去取的呢？

这一点非常重要，在oAuth 2中，永远不会有密码传递的事情发生。

我们来仔细分析一下上面的过程, 

首先这个Test应用会像微信的授权服务发送一个授权请求。

其次，微信的授权服务会发送一个页面给你的应用。要求你确认是否授权给这个应用。

接下来你确认授权，你的应用会把这个授权的信息发送给微信的授权服务。

接下来微信的授权服务会向你的应用发送一个访问码。

你的应用拿到这个访问码以后就会像微信的资源服务发送信息获取请求。

微信的资源服务就会返回这个Test应用想要的信息。

要想让上面的工作流程工作顺畅的话，我们需要把Test应用的信息注册在微信服务系统中， 这些信息一般包括如下，一个是名字，一个是网站站点，一个是callback的链接， 这些信息在微信服务系统中注册以后，会获取一个是客户识别号，还有一个客户密钥。有了这两个东西以后，我们在Test应用中就需要使用这个识别号和密钥来向微信服务系统发出请求，这就是我们刚开始说的流程的开始。

现在小结一下。

在oAuth 2中有4种授权方式， 上面我们举的例子是用验证码授权的方式。

其他三种授权方式分别是隐藏式授权， 密码授权和用户登录信息授权。

在oAuth 2中经常谈到的两个服务，一个是验证服务，一个是资源服务。使用两个服务的载体就是我们的应用。

这一期就说这些，希望对大家有所帮助。

这里是丁哥开讲，欢迎关注一起学习讨论，共同进步。