简单认识 OAuth2.0 协议

1.前言

OAuth2.0 是近几年比较流行的受权机制，对于普通用户来讲可能天天你都在用它，咱们常用的第三方登陆大都基于 OAuth2.0。
随着应用的互联互通，个性化服务之间的相互调用，开放性的受权成为客观的须要。

2. OAuth2.0 的简单认识

OAuth 定义了以下角色，并明确区分了它们各自的关注点，以确保快速构建一致性的受权服务：

• Resource Owner 资源拥有者，一般指的是终端用户，其做用是赞成或者拒绝、甚至是选择性的给第三方应用程序的受权请求。
• User Agent 用户代理 指的的资源拥有者受权的一些渠道。通常指的是浏览器、APP
• Client 请求受权和请求访问受限资源的客户端程序。
• Authorization Server 对用户受权进行鉴别并根据鉴别结果进行赞成或拒绝的受权响应的服务器。
• Resource Server 可以接受和响应受保护资源请求的服务器。

单纯的文字性描述是否是有些难以理解。

因此我这里讲一个亲身经历的事例来情景化以上的四个概念。

立刻又到程序员集中面试的季节了，有一年我去面试，到了地方才发现如此的“高大上”，访客须要经过验证码才能经过闸门，我联系了面试公司的 HR,HR 确认后微信发给我了一个连接，打开后是一个微信小程序给出了如下流程:

• 我向面试公司（HR）发送了一个进门的要求。
• HR 给了我一个能够获取进门许可请求的连接。
• 我经过连接进行进门许可请求。
• 请求获得响应，返给我一个验证码。
• 我在闸门程序中输入验证码。
• 验证经过后放行。

在我学习了 OAuth2.0 协议以后我发现此次经历能够体现出 OAuth2.0 的一些设计理念。
访客必须经过受权才能访问大楼。

这种方式避免了闲杂人等出入办公场所，并且对访客可控（从访问时间和次数上），甚至能够实现对楼层的访问可控（固然上面的例子中没有）。

再结合 OAuth2.0 能够知道 访客就是 Client，公司（业主）就是 Resource Owner，物业就是 Authorization Server ，那个闸机就是 Resource Server，闸机有可能也受到物业的管控。

这是那张著名的流程图：

这个例子只是为了快速的来认识 OAuth2.0 ，它是一种有效的、可靠的委托受权框架。

它提供了多种受权模式在不一样的场景下供你选择。

3. 受权模式

为了得到访问许可，客户端须要向受权服务器出示有效的受权凭证，也就是说客户端必须获得用户受权（authorization grant）如下是受权方式的表格：

其中前五种为咱们所熟知。咱们后续会详细介绍它们。

4. OAuth 2.0 的一些要点

摘自《OAuth 2 实战》：

因为 OAuth2.0 被定义为一个框架，对于 OAuth2.0 是什么和不是什么，一直未明确。咱们所说的 OAuth2.0 是指 OAuth2.0 核心规范中定义的协议，RFC 6749[1] 核心规范详述了一系列获取访问令牌的方法；还包括其伴随规范中定义的 bearer 令牌，RFC 6750[2]该规范规定了这种令牌的用法。获取令牌和使用令牌这两个环节是 OAuth2.0 的基本要素。正如咱们将在本节中看到的，在更普遍的 OAuth2.0 生态系统中存在不少其余技术，它们配合 OAuth2.0 核心，提供更多 OAuth2.0 自己不能提供的功能。咱们认为，这样的生态系统是协议健康发展的体现，可是不该与协议自己混为一谈。

基于以上的原则 OAuth2.0 有如下一些要点须要明确被认识到：

•  OAuth2.0 并不是身份认证协议，虽然在受权的过程当中涉及到身份认证，可是 OAuth2.0 协议自己并不处理用户的信息。客户端访问受保护的资源时并不关心资源的拥有者。
• OAuth2.0 不提供一些消息签名，为了保证安全性因此不该脱离 Https 。在使用其它协议或者系统时也应该明确一个安全机制来承担 Https 所承担的任务。
• OAuth2.0 并无定义加密方式，虽然目前使用的较多的是 JOSE 规范[3]
• OAuth2.0 虽然令牌被客户端持有并使用，可是客户端并不能解析以及处理令牌。
• 5. 总结

OAuth2.0 其实还有个特色，它并非单体协议。它被分红了多个定义和流程，每一个定义和流程都有各自的应用场景。因此本文的目的在于场景化的引入 OAuth2.0，当你渐入佳境时，咱们再来进行细节的探讨吧。