OAuth2.0指南(二)
- OAuth2.0授权
当一个客户单应用想要访问资源拥有者托管在资源服务器的资源时，它必须先获得授权，本节将讲述客户端授权怎么获取。
客户端标识，客户端密钥和重定向URI
在客户端应用能请求访问资源服务器的资源之前，客户端应用程序必须先注册与资源服务器相关联的授权服务器。
注册一个典型的一次性任务。一旦注册了，除非客户端注册被取消了，注册将持续有效。
注册后客户端应用将由授权服务器分配客户端标识和密钥。在授权服务器上，客户端标识和密钥是唯一标识客户端应用的。如果客户端应用注册了多个授权服务器(如Facebook, Twitter和Google等)，每一个授权服务器将发出唯一的标识给该客户端应用。
无论什么时候客户端应用想要访问同样资源服务器上的资源，它都需要通过发送客户端标识和密钥到授权服务器来验证自己。
在注册过程中，客户端应用也注册了一个重定向URI，当资源拥有者授权给客户端应用时，该重定向URI会被使用。当资源拥有者成功的通过授权服务器授权给客户端应用时，资源拥有者被重定向回客户端应用，再到该重定向URI。
- 授权批准
授权批准由资源服务器，及与其相关的授权服务器，给予客户端应用。
OAuth2.0列举四种不同类型授权批准，每一种类型都有不同的安全特性。这些授权批准类型为：
- 授权码
- 契约
- 资源拥有者密钥证书
- 客户端证书
每种授权批准再下文都会提到。
授权码
用授权码来授权批准原理如下：
资源拥有者(用户)访问客户端应用。客户端应用告诉用户通过授权服务器(如Facebook, Google和Twitter等)来登录到客户端应用。
为了通过授权服务器登录，用户通过客户端应用被重定向到授权服务器。客户端应用发送它的客户端标识给授权服务器，那么授权服务器就知道是哪个应用尝试访问受保护的资源。当被重定向回客户端应用时，授权服务器发送给用户特定的重定向URI, 即客户端已经提前与授权服务器注册。随着重定向，授权服务器发送一个代表授权的授权码。
当在客户端应用的重定向URI被访问时，客户端应用直接连接授权服务器。客户端应用发送授权码，客户端标识及密钥，如果客户端应用能接受这些值，那么授权服务器返回一个访问令牌。
现在客户端应用就可以用该访问令牌请求资源服务器的资源了。该访问令牌可作为客户端授权和授权访问资源。
下面是当用授权码授权客户端应用时的授权过程：
通过授权码授权
契约
契约授权类似于授权码授权，除了用户完成授权后，访问令牌返回给客户端应用外。当用户代理被重定向到重定向URI时，访问令牌因此被返回。
当然这意味着访问令牌可以被用户代理访问，或者在契约授权过程中参与的原生应用。访问令牌在web服务器上不是安全存储的。
进一步说，客户端应用可以只发送它的客户端标识给授权服务器。如果客户端也发送它的密钥，那么客户端密钥将不得不保存在用户代理或原生应用里。那将使得它很容易被破解。
契约授权大多数用在用户代理或原生应用中。用户代理或原生应用将收到来授权服务器的访问令牌。
下面是阐释契约授权的图：
契约授权
资源拥有者密钥证书
资源拥有者证书授权方法通过客户端应用访问资源拥有者证书来工作。比如，用户可以在客户端应用输入他的Twitter用户名及密钥(证书)。该客户端应用就可以用着用户名和密钥访问用户在Twitter的资源。
用资源拥有者密钥证书要求客户端应用很多信任。你不想在那些你怀疑会滥用证书的客户端应用中输入证书。
资源拥有者密钥证书通常被用在用户代理或原生应用中。
客户端证书
客户端证书授权对于客户端需要在资源服务器访问资源或调用函数的情形使用，与特定的资源拥有者无关(如用户)。比如，从Foursquare获取场地列表，这并没有必要通过某个Foursquare用户才能做。
- OAuth2.0端点
OAuth2.0定义了一系列端点。端点典型的就是web服务器上的URI。比如，一个Java Servlet, JSP page, PHP page, ASP.NET网页等等。
这些端点定义有：
- 授权端点
- 令牌端点
- 重定向端点
授权端点和令牌端点都位于授权服务器上，重定向端点位于客户端应用上。每个端点都会在下面讲述。
这些端点在下图中阐释为：
OAuth2.0端点
OAuth2.0规范没有描述这些端点怎么被发现或记录。这取决于咩哥实现者来决定。大多数网站都有一个子网站来的开发人员来记录这些端点。
授权端点
授权端点是资源拥有者所登录的授权服务器，并授权给客户端应用的端点。
令牌端点
令牌端点是在授权服务器上为了一个访问令牌，客户端应用要交换授权码，客户端标识和客户端密钥的端点。
重定向端点
重定向端点是在授权端点授权以后，资源拥有者被重定向到客户端应用的端点。
（全文完）如果您喜欢此文请点赞，分享，评论。
- 原创文章转载请注明出处：OAuth2.0指南(二)