OAuth 授权协议 | 都云原生时代了，我们应该多懂一点OAuth ？
We are not here because we are free .we are here because we are not free.
我们在这里不是因为我们自由，我们在这里是因为我们不自由。——《黑客帝国》
写在开头
在这个互联网最美好的时代，随着业务产品线的增多，业务应用平台逐渐增多后，每个系统单独管理各自的用户数据容易形成信息孤岛，分散的用户管理模式阻碍了企业应用向平台化演进。当业务产品线发展到一定规模，构建统一的标准化账户管理体系将是必不可少的，构建一套互联网云平台的重要基础设施，能够为平台带来统一的帐号管理、身份认证、用户授权等基础能力，为企业带来诸如跨系统单点登录、第三方授权登录等基础能力，为构建开放平台和业务生态提供了必要条件和基本准绳。
关于OAuth授权协议的问题，也许我们中的大多数都还是从玩Github 开始的，或者就是从阮一峰的网络日志看到的，不论是何种情况下接触到OAuth的。我们都要相信，OAuth的正确打开方式，绝对不是三言两语的事情，需要经过系统的分析和项目实战，才会有不一样的味道，不然我们遇到的都是坏味道。
OAuth授权协议
An open protocol to allow secure API authorization in a simple and standard method from web, mobile and desktop applications.
基本定义
OAuth授权协议为用户资源的授权提供了一个安全的、开放而又简易的标准。与以往的授权方式不同之处是OAUTH的授权不会使第三方触及到用户的帐号信息（如用户名与密码），即第三方无需使用用户的用户名与密码就可以申请获得该用户资源的授权，因此OAUTH是安全的。OAuth是Open Authorization的简写。
一般来说，OAuth是一个授权协议，它允许软件应用代表（而不是充当）资源拥有者去访问资源拥有者的资源。应用向资源拥有者请求授权，然后取得令牌（token），并用它来访问资源，并且资源拥有者不用向应用提供用户名和密码等敏感数据。目前常用的是2.0版本，又称为OAuth 2.0 。从官网来看，新版本2.1不久面世。
其实挑点实际话讲，OAuth 2.0 并不是一门新的技术，从 2007 年 OAuth 1.0 面世，到 2011 年发布 OAuth 2.0 草案。但是，看似简单的 OAuth 2.0 会让我们望而却步，在如何使用授权码流程上踌躇不前。比如，在 Web 应用中到底应该怎么使用授权码流程，移动 App 中还能使用授权码流程吗？
当我带着这些问题尝试到网上搜索资料时，那些不成体系的资料着实也让我走了不少弯路。不知道你是不是也被下面问题困扰着：
- 开发一个 Web 应用，当使用 OAuth 2.0 的时候，担心授权码被拦截，却因为没有较好的解决方法而一筹莫展
- 开发一款移动 App，当使用 OAuth 2.0 的时候，在确定是否需要 Server 端上，花费了大把的时间
- 开发一个小程序，当使用 OAuth 2.0 的时候，在确定是否需要 Server 端上，需要考虑的场景是否足够多
- 开发一个面向多产品的统一授权认证平台时，比如open-iam，对于PC平台，后台平台，门户平台，移动端APP平台，小程序平以及大数据监控平台，这样的一个需求时，当使用 OAuth 2.0 的时候，是否能实现和满足需求
- 开发一个统一授权认证平台，对于用户和资源之间如何界定设置，前后端分离模式，又如何保证用户登录实现平台的跳转和通信
- 在不同架构模式背景下，对于OAuth的使用，其中的技术选型又会有怎样的差异，更多情况下，我们的技术选型是否可取
从大方向上总结来看，OAuth 2.0 这种授权协议，就是保证第三方（软件）只有在获得授权之后，才可以进一步访问授权者的数据。因此，我们常常还会听到一种说法，OAuth 2.0 是一种安全协议。现在访问授权者的数据主要是通过 Web API，所以凡是要保护这种对外的 API 时，都需要这样授权的方式。而 OAuth 2.0 的这种颁发访问令牌的机制，是再合适不过的方法了。同时，这样的 Web API 还在持续增加，所以 OAuth 2.0 是目前 Web 上重要的安全手段之一。
基本规范
OAuth 2.0 的标准是 RFC 6749 文件。OAuth 引入了一个授权层，用来分离两种不同的角色：客户端和资源所有者。资源所有者同意以后，资源服务器可以向客户端颁发令牌。客户端通过令牌，去请求数据。也就是说，OAuth 的核心就是向第三方应用颁发令牌。
按照一般软件系统开发定义开看，一个 OAuth 标准应用规范都有如下几个定义规范，或者说基本角色：
- Third-party /Client application：第三方应用端程序，一般系统平台都称“客户端”（client）。代表资源拥有者访问受保护资源的软件，它使用OAuth 来获取访问权限。
- HTTP service：HTTP服务提供商，一般系统平台都简称“服务提供商”。
- Resource Owner：资源所有者，一般系统平台都称“用户”（user），即登录用户。是有权将访问权限授权给客户端的主体，在大多数情况下，资源拥有者是一个人，他使用客户端软件访问受他控制的资源；
- User Agent：用户代理，一般系统平台就是指浏览器。
- Authorization server：认证服务器，即服务提供商专门用来处理认证的服务器。一个HTTP 服务器，它在OAuth 系统中充当中央组件。授权服务器对资源拥有者和客户端进行身份认证，让资源拥有者向客户端授权、为客户端颁发令牌。某些授权服务器还会提供额外的功能，例如令牌内省、记忆授权决策
- Resource server：资源服务器，即服务提供商存放用户生成的资源的服务器。它与认证服务器，可以是同一台服务器，也可以是不同的服务器。资源服务器能够通过HTTP 服务器进行访问，在访问时需要OAuth 访问令牌。受保护资源需要验证收到的令牌，并决定是否响应以及如何响应请求。
这里必须强调一点的是，这里说的第三方，大多数指的是区别于当前应用系统的其他应用，包括不限于微信，QQ，新浪，抖音，今日头条等等。按照正常的系统的应用来说，在所用系统之前，都会有一个类似于open-iam身份识别与访问管理的系统的,至少来讲都会有这么一个系统组件的。这样来说，这个IAM应用平台在多产品业务线，甚至说是多租户场景模式来说，这是一个系统底层架构的核心元组件，所有其他的业务应用系统，都是围绕这个组件来进行整合和糅合其他的业务需求的，如图所示：
其实不论在单体架构时代，还是分布式(RPC)服务时代，以及眼花缭乱微服务时代，还是现在都在追捧的云原生架构时代，授权和认证应用模块在日常开发里，基本上是一个框架的底层组件来构建和关联第三方软件以及其他应用的。互联网中所有的受保护资源，几乎都是以 Web API 的形式来提供访问的。每次都是用访问令牌而不是用户名和密码来请求用户的数据，才大大减少了安全风险上的“攻击面”，至少从系统架构层面来说，引入 OAuth 主要还是为项目架构底层保驾护航。
基本流程
在一个日常应用系统里，对于Oauth应用的系统流转流程如下：
但是实际上，对于OAuth2 的工作原理我们通过结构化思维的拆解分析可以发现，Oauth应用的最终目的，是要获取一个叫做“访问令牌”的东西。在业务系统获取到访问令牌之后，才有足够的 “能力” 去请求系统拿到系统给我授权的资源列表数据。不论是任何终端应用，访问我们提供的统一授权服务，几乎都需要依托Oauth来经历和经过如下流程：
其中，OAuth 授权的核心就是颁发访问令牌、使用访问令牌。比如，业务应用系统访问统一鉴权管控平台，其间统一鉴权管控平台会依据业务应用系统的需要(请求参数)，为其生成授权码，业务应用系统拿到授权码表示得到了授权，再次访问统一鉴权管控平台，后续验证完毕生成访问令牌，返回业务应用系统，最后业务应用系统拿到访问令牌，去查询对应的授权资源列表和数据，这就是使用访问令牌。其中主要的动作，就是生成授权码–> 生成访问令牌–> 使用访问令牌。其中授权码许可（Authorization Code）类型。它是 OAuth 2.0 中最经典、最完备、最安全、应用最广泛的许可类型。除了授权码许可类型外，OAuth 2.0 针对不同的使用场景，还有 3 种基础的许可类型，分别是隐式许可（Implicit）、客户端凭据许可（Client Credentials）、资源拥有者凭据许可（Resource Owner Password Credentials）。
总结来说，OAuth 授权有 3 个关键点：
- OAuth 2.0 的核心是授权许可，更进一步说就是令牌机制。对于业务应用系统来说，只有拿到颁发的访问令牌，也就是得到了授权许可，然后才可以代表用户访问他们的数据。
- 互联网中所有的受保护资源，几乎都是以 Web API 的形式来提供访问的。我们说 OAuth 2.0 与安全相关，是用来保护 Web API 的。另外，第三方软件通过 OAuth 2.0 取得访问权限之后，用户便把这些权限委托给了第三方软件，我们说 OAuth 2.0 是一种委托协议，也没问题。
- 业务应用系统对于统一鉴权管控平台算是客户端，统一鉴权管控平台是服务端，而且是独立部署服务的，每次都是用访问令牌而不是用户名和密码来请求用户的数据，才大大减少了安全风险上的“攻击面”。
版权声明：本文为博主原创文章，遵循相关版权协议，如若转载或者分享请附上原文出处链接和链接来源。
