简述 OAuth 2.0 的运作流程

本文将以用户使用 github 登录网站留言为例，简述 OAuth 2.0 的运作流程。

假如我有一个网站，你是我网站上的访客，看了文章想留言表示「朕已阅」，留言时发现有这个网站的帐号才能够留言，此时给了你两个选择：一个是在我的网站上注册拥有一个新账户，然后用注册的用户名来留言；一个是使用 github 帐号登录，使用你的 github 用户名来留言。前者你觉得过于繁琐，于是惯性地点击了 github 登录按钮，此时 OAuth 认证流程就开始了。

需要明确的是，即使用户刚登录过 github，我的网站也不可能向 github 发一个什么请求便能够拿到访客信息，这显然是不安全的。就算用户允许你获取他在 github 上的信息，github 为了保障用户信息安全，也不会让你随意获取。所以操作之前，我的网站与 github 之间需要要有一个协商。

1. 网站和 Github 之间的协商

Github 会对用户的权限做分类，比如读取仓库信息的权限、写入仓库的权限、读取用户信息的权限、修改用户信息的权限等等。如果我想获取用户的信息，Github 会要求我，先在它的平台上注册一个应用，在申请的时候标明需要获取用户信息的哪些权限，用多少就申请多少，并且在申请的时候填写你的网站域名，Github 只允许在这个域名中获取用户信息。

此时我的网站已经和 Github 之间达成了共识，Github 也给我发了两张门票，一张门票叫做 Client Id，另一张门票叫做 Client Secret。

2. 用户和 Github 之间的协商

用户进入我的网站，点击 github 登录按钮的时候，我的网站会把上面拿到的 Client Id 交给用户，让他进入到 Github 的授权页面，Github 看到了用户手中的门票，就知道这是我的网站让他过来的，于是它就把我的网站想要获取的权限摆出来，并询问用户是否允许我获取这些权限。

// 用户登录 github，协商  GET https://github.com/login/oauth/authorize    // 协商凭证  params = {    client_id: "xxxx",    redirect_uri: "http://my-website.com"  }

// 协商成功后带着盖了章的 code  Location: http://my-website.com?code=xxx

// 网站和 github 之间的协商  POST https://github.com/login/oauth/access_token    // 协商凭证包括 github 给用户盖的章和 github 发给我的门票  params = {    code: "xxx",    client_id: "xxx",    client_secret: "xxx",    redirect_uri: "http://my-website.com"  }

// 拿到最后的绿卡  response = {    access_token: "e72e16c7e42f292c6912e7710c838347ae178b4a"    scope: "user,gist"    token_type: "bearer",    refresh_token: "xxxx"  }

// 访问用户数据  GET https://api.github.com/user?access_token=e72e16c7e42f292c6912e7710c838347ae178b4a

// 告诉我用户的名字和邮箱  response = {    username: "barretlee",    email: "barret.china@gmail.com"  }