tips：本文为github-API关于授权账号登录其他网站开发文档的个人中文翻译，官网文档对应：Authorizing OAuth Apps
授权OAuth应用程序
你可以授权github账号登录其他网站
Github的授权实现支持标准授权码授权类型。你可以用下面描述的web应用流程去获取授权code，然后用code去交换获取token。（不支持隐式授权类型）
遇到问题可以参见下面的文章：
- 认证请求错误汇总
- OAuth应用获取token请求错误汇总
Web应用授权流程
Note: 如果建立了一个Github应用，仍然可以使用OAuth web应用流程，不过二者在方案上还是有区别的。更多内容可见关于Github应用认证和授权用户
应用授权用户步骤如下：
- 用户重定向去请求Github认证
- 用户从github重定向回到你的web
- 你的应用通过access token获取到了API
1. 请求Github认证
GET https://github.com/login/oauth/authorize
当你的Github应用指定了login参数，它会给用户一个特定的账户去登录和授权你的应用。
参数
| Name | Type | 说明 |
|---|---|---|
| client_id | string | 必需有。当你注册Github授权应用时产生的client ID |
| redirect_uri | string | Github授权后返回你的应用地址。更多细节参考redirect urls |
| login | string | 意味着一个用来登录和授权应用的特定账户 |
| scope | string | 以空格分隔的scope列表。如果此处为空，scope默认对用户是一个空的列表，即没有对应用授权任何scope，在OAuth授权页面的scopes列表中也不会有该用户。对应地，这一步工作流程将会自动完成授权应用的用户scope集。例如，一个用户已经执行web授权流程两次，用userscope和reposcope各授权了一次，那么第三次web流程没有提供scope时也会受到前面userscope和reposcope得到的token。 |
| state | string | 一个不可预计的随机字符串，被用作为保护伪造跨域请求攻击。 |
| allow_signup | string | 无论用户是否认证，都将被提供一个选项在OAuth流程中是否要注册Github。默认是true，在政策禁止注册下可使用false。 |
2. 用户从Github重定向回到你的网站
如果接受了你的请求，Github会重定向回到你的网站，并携带一个临时的code在code参数中，还在state参数中携带了上一步你提供的state。临时的code将在10分钟后失效。如果states不匹配，那么第三方将会创建请求，并且你需要中断当前操作。
用code取交换获取access token:
POST https://github.com/login/oauth/access_token
参数
| Name | Type | 说明 |
|---|---|---|
| client_id | string | 必需有。当你注册Github授权应用时产生的client ID |
| client_secret | string | 必需有。当你注册Github授权应用时产生的client secret |
| code | string | 必需有。你收到的code是对应step1中的 |
| redirect_uri | string | 是你应用中的URL，这个地址用作用户授权返回地址 |
| state | string | step1中你提供的随机字符串 |
响应
通常，得到的响应一般为下面这种形式：
access_token=e72e16c7e42f292c6912e7710c838347ae178b4a&token_type=bearer
你也有可能因为Accpt header形式的不同接收到不同的内容
Accept: application/json
{"access_token":"e72e16c7e42f292c6912e7710c838347ae178b4a", "scope":"repo,gist", "token_type":"bearer"}
Accept: application/xml
bearer
repo,gist
e72e16c7e42f292c6912e7710c838347ae178b4a
3. 利用access token去获取API
access token可以让你以用户的身份请求API
Authorization: token OAUTH-TOKEN
GET https://api.github.com/user
例如，你可以像下面这样用curl设置header：
curl -H "Authorization: token OAUTH-TOKEN" https://api.github.com/user
非Web应用授权流程
基于Basic Authentication利用接口去创建OAuth2 token。通过这种方法，用户名和密码不需要被永久存储，而且用户可以在任何时候撤销access。
Note: 当使用非Web应用授权流程创建OAuth2 token时，如果你或你的用户是双重认证的话，应确保理解双重认证机制
Redirect URLs
redirect_uri参数是可选的。如果省略，Github将重定向用户到callback URL，这一地址被配置在了OAuth Application settings部分。如果提供了，redirect URL的主机和端口必须准确匹配callback URL。redirect URL路径必须引用callback URL的子目录。
CALLBACK: http://example.com/path
GOOD: http://example.com/path
GOOD: http://example.com/path/subdir/other
BAD: http://example.com/bar
BAD: http://example.com/
BAD: http://example.com:8080/path
BAD: http://oauth.example.com:8080/path
BAD: http://example.org
为OAuth应用创建多个token
你可以为user/application/scope组合创建多个token用作特定用途。
如果你的OAuth应用支持使用Github登录，并且一个工作流只需要用户的基本信息，另一个工作流可能需要获取用户私有资料，这样创建多个token是可行的。使用多个token，你的OAuth应用就可以根据不同用途执行不同web工作流，只需要请求scope需要的。如果一个用户仅使用你的应用去登录，他们就不会去授权你的OAuth应用去获取他们的私有资料。
每次的user/application/scope组合发布的token数量有限定，如果你的应用对其中一个限定请求了足够多的token，那么位于同一scope的旧token就会停止工作。
Warning: 撤销OAuth应用的所有许可会删除代表应用产生的表征用户的所有SSH keys，其中包括deploy keys。
重定向用户去检查他们的access
你链接到OAuth应用的授权信息，用户就可以检查和取消他们的应用授权。
为了建立这个链接，需要注册OAuth应用时从Github接收到的client_id。
https://github.com/settings/connections/applications/:client_id
tips: 了解更多关于OAuth应用访问用户详见"Discovering resources for a user."