Oauth2.0这个东西也困扰我好久了，今天借助《Getting Started with OAuth2.0》这本书弄明白这个东西。
相关技术
Authentication（身份认证）
Authentication是验证用户身份的过程，判定用户是否是他们所声称的那个。在现实世界中，当一个警察想验证你的身份时，他会请你拿出身份证，然后对照你的长相。而在网络世界中，同样需要验证，判定正在敲键盘的用户是不是账号的所有者。传统的验证一般需要两项信息：用户名和密码。
Federated Authentication（联合身份认证）
虽然很多应用有自己的账户系统（包括用户名和密码），但是也有一些拥有是依靠其他的服务去验证用户的，这样的情况就叫做Federated Authentication（联合身份验证）。典型的一种联合身份认证的方式是OpenID，这里不做过多的探讨，我们只探讨其中的OpenID Connect —— 基于OAuth2.0的下一代版本的OpenID。
Authorization（授权）
Authorization是判定一个用户是否有权利做某些行为的过程，比如，阅读一个文档、进入一个email账户。这首先就需要一个合法的身份信息（authorization）来检测是否是真实的用户被授权。当一个警察发现你超速的时候，他首先要检查你是否有驾驶证（验证你的身份信息），之后检查你的证件上的信息，证件是否过期，是否被限制。同样的过程在网上发生，web应用会验证你的身份，接下来逐项检查访问控制列表，已确保只有被允许的数据可以访问。
Delegated Authorization （委托授权）
Delegated Authorization是指另一个人或者应用代替你执行。当你开车到达一个豪华酒店，会有服务员为你停车，你需要把车钥匙给服务员，并且授权他代替你执行停车的动作。OAuth做的事情与这相仿，用户允许一个应用代替自己的身份执行一些操作，而这个应用所能做的操作只能在被授权的范围内。
Roles（角色）
在OAuth协议流程中有几个关键角色：
Resource server（资源服务器）
通过OAuth保护，储存用户资源的服务器。第一方。
Resource owner （资源拥有者）
一个应用的用户，资源拥有者有访问他们在资源服务器上储存的数据的权限。第二方。
Client （客户端）
一个代替用户身份访问资源服务器的应用，需要得到用户的授权。第三方。
Authorization server （授权服务器）
授权服务器从资源拥有着那得到同意权限，颁发access tokens，使客户端有访问资源服务器中资源的权限。很多时候，如果提供数据的服务商不是很大的话，授权服务器和资源服务器会放到一起，通过不同的URL访问。
关于证书的巨大争论
在OAuth1.0的时候，每一次去验证身份的API请求都需要携带加密证书，但加密对于初级的开发者来说很难，就算是高级的开发者，想精通加密也非易事，这导致了开发者对API的接受度较低。OAuth1.0开发的时间是2007年，那个时候SSL/TLS还没有流行，几年以后，SSL/TLS作为了加密证书的代替方案。在OAuth2.0中，加密证书被移除，代替的是引入持有者令牌的使用。
但也有一些人反对证书的移除，主要是站在安全性上考虑，具体可参看 OAuth 2.0 (without Signatures) Is Bad for the Web。安全性与实用性的平衡，一直是软件开发的重要争论点。
开发者及应用注册
一般你需要到你想介入的网站上注册，我这里以GiHub为例，可以看到注册之后的应用界面:
这里有两个重要的东西：
- Client ID : 当你连接资源服务器时，的唯一编号。
- Client Secret : 当需要改变授权代码或者更新access token时用到。
为什么注册是必要的
注册使开发者从授权服务器那里获得客户端资格，这个资格对一些操作很重要，比如，改变授权代码，更新访问令牌。注册也可以提高用户在授权过程中的体验，一般API提供者会在授权过程中提供第三方应用的名称和logo。
Client Profiles, Access Tokens, and Authorization Flows
在OAuth1.0中，API授权被设计成指支持传统的client-server应用。这使得其不支持手机应用、桌面应用、JavaScript应用、浏览器扩展等类型的应用。这些在OAuth2.0中得到了改变。
Client Profiles（客户端配置）
OAuth2.0定义了几种重要的客户端配置：
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
