我们不在这里是因为我们是自由的。我们在这里是因为我们不自由。我们来这里不是因为我们是自由的。我们在这里是因为我们不自由。——♂写在开头在互联网最美好的时代，随着业务产品线和业务应用平台的增多，各个系统独立管理自己的用户数据，很容易形成信息孤岛，去中心化的用户管理模式阻碍了企业应用向平台化的演进。当业务产品线发展到一定规模后，构建统一规范的账户管理系统将必不可少。构建互联网云平台的重要基础设施，可以为平台带来统一的账号管理、身份认证、用户授权等。基础能力，为企业带来跨系统单点登录、第三方授权登录等基础能力，为构建开放平台和商业生态提供必要条件和基础指引。关于OAuth授权协议的问题，可能我们大多数人都是从玩Github开始的，或者是从阮一峰的网络日志看到的，不管是什么情况下，我们都接触到了OAuth。想必大家都相信OAuth的正确打开方式绝对不是三言两语的事情。需要系统的分析和实际的项目实战才能有不一样的味道，不然我们都会遇到不好的味道。OAuth授权协议一种开放协议，允许通过Web、移动和桌面应用程序以简单且标准的方法进行安全API授权。基本定义OAuth授权协议为用户资源的授权提供了一个安全、开放、简单的标准。与以往授权方式不同的是，OAUTH授权将不允许第三方触及用户的账户信息（如用户名和密码），即第三方可以在不使用用户的用户名和密码的情况下申请访问用户的资源密码。授权，所以OAUTH是安全的。OAuth是开放授权的缩写。一般来说，OAuth是一种授权协议，允许软件应用程序代表（而不是作为）资源所有者访问资源所有者的资源。应用程序向资源拥有者请求授权，然后获得一个令牌（token），并使用它来访问资源，资源拥有者不需要向应用程序提供用户名和密码等敏感数据。目前常用的是2.0版本，也称为OAuth2.0。从官网来看，2.1新版本即将发布。其实，用实际的话来说，OAuth2.0并不是什么新技术。从2007年OAuth1.0的推出，到2011年OAuth2.0草案的发布。然而，看似简单的OAuth2.0会让我们望而却步，犹豫如何使用授权码流程。比如授权码流程在web应用中应该如何使用，授权码流程是否可以在移动端app中使用？当我带着这些问题试图在网上搜索资料时，不系统的资料着实让我走了很多弯路。不知道你是否也被以下问题所困扰：在开发web应用的时候，在使用OAuth2.0的时候，担心授权码会被拦截，但是因为没有更好的解决方案，所以一头雾水开发移动应用程序。当使用OAuth2.0使用OAuth2.0时，花了很多时间开发一个小程序来确定是否需要服务器。使用OAuth2.0时，考虑的场景是否足以开发面向PC平台、后台平台、门户平台、手机APP平台、小程序平台、大数据的多产品统一授权认证平台，如open-iam监控平台，当有这样的需求时，在使用OAuth2.0时，是否能够实现并满足开发统一授权认证平台的需求，如何定义用户与资源之间的设置，前后端分离模式，以及如何保证用户登录实现平台跳转和通信。在不同架构模式的背景下，对于OAuth的使用，在技术选择上会有什么样的差异？更多情况下，我们的技术选择是否可取从一般的角度来看，OAuth2.0授权协议是为了保证第三方（软件）只有在获得授权后，才有可能进一步访问授权方的数据。因此，我们也经常听说OAuth2.0是一种安全协议。现在访问授权方的数据主要是通过WebAPI，所以每当要保护这种外部API的时候，就需要这样的授权方式。用于颁发访问令牌的OAuth2.0机制非常适合。同时，此类WebAPI还在不断增加，因此OAuth2.0是目前Web上重要的安全手段之一。OAuth2.0的基本规范是RFC6749文档。OAuth引入了一个授权层来分隔两个不同的角色：客户端和资源所有者。资源所有者同意后，资源服务器可以向客户端颁发令牌。客户端通过令牌请求数据。也就是说，OAuth的核心就是给第三方应用颁发token。按照通用软件系统开发的定义，一个OAuth标准应用规范有如下定义规范，或者说基本角色：Third-party/Clientapplication：第三方应用程序，通用系统平台称为“客户端”（client）.代表资源所有者访问受保护资源的软件，使用OAuth获得访问权限。HTTP服务：HTTP服务提供者，一般系统平台简称为“服务提供者”。ResourceOwner：资源所有者，一般系统平台称为“用户”（user），即登录用户。有权向客户端授权访问权限的是主体。在大多数情况下，资源所有者是使用客户端软件访问其控制下的资源的人；UserAgent：用户代理，一般系统平台指的是浏览器。Authorizationserver：认证服务器，即服务提供商专门用来处理认证的服务器。作为OAuth系统中的中央组件的HTTP服务器。授权服务器对资源拥有者和客户端进行身份验证，允许资源拥有者对客户端进行授权，并为客户端颁发令牌。一些授权服务器还会提供额外的功能，比如tokenintrospection，内存授权决策Resourceserver：资源服务器，即服务提供者存储用户产生的资源的服务器。它和认证服务器可以是同一台服务器，也可以是不同的服务器。可以通过HTTP服务器访问资源服务器，访问需要OAuthaccesstoken。受保护的资源需要验证收到的令牌并决定是否以及如何响应请求。这里必须强调的是，这里所说的第三方大多是指不同于当前应用系统的其他应用，包括但不限于微信、QQ、新浪、抖音、今日头条等。正常的系统，在系统使用之前，都会有类似open-iam的身份识别和权限管理的系统，至少会有这么一个系统组件。这样，这个IAM应用平台在多产品业务线，甚至多租户场景模式下，都是系统底层架构的核心组件。所有其他业务应用系统都围绕这个组件进行集成。而那些结合了其他业务需求的，如图：其实不管是单体架构时代，分布式（RPC）服务时代，还是眼花缭乱的微服务时代，还是现在被追捧的云原生架构时代、授权和认证在日常开发中，应用模块基本上是一个框架的底层组件，用于构建和关联第三方软件和其他应用。Internet上几乎所有受保护的资源都是以WebAPI的形式访问的。每次都使用accesstoken代替用户名和密码来请求用户的数据，大大减少了安全风险的“攻击面”。至少从系统架构上来说，引入OAuth主要是为了保护项目架构的底层。基本流程在日常的应用系统中，Oauth应用的系统流程如下：但实际上，对于OAuth2的工作原理，我们可以发现，Oauth应用的最终目的是获取一个名为“AccessToken”的系统“东西。业务系统获得accesstoken后，有足够的“能力”请求系统获取系统授权的资源列表数据。无论是任何终端应用，访问我们提供的统一授权服务几乎都需要依赖Oauth来完成，并经过以下流程：其中，OAuth授权的核心是发放访问令牌和使用访问令牌。例如，当业务应用系统访问统一认证管控平台时，统一认证管控平台会根据业务应用系统的需要（请求参数）为其生成一个授权码。统一认证管控平台后续校验后生成访问令牌返回给业务应用系统。最后，业务应用系统获取accesstoken，查询对应的授权资源列表和数据。这是访问令牌的使用。主要动作是生成授权码->生成访问令牌->使用访问令牌。其中，授权码权限（AuthorizationCode）类型。是OAuth2.0中最经典、最完整、最安全、使用最广泛的权限类型。除了授权码权限类型，OAuth2.0针对不同的使用场景，还拥有三种基本权限类型，分别是隐式权限（Implicit）、客户端凭证权限（ClientCredentials）、资源所有者凭证权限（ResourceOwnerPasswordCredentials）。总结起来，OAuth授权有3个关键点：OAuth2.0的核心是授权权限，更具体地说是token机制。对于业务应用系统来说，只有获得颁发的accesstoken，即获得授权后，才能代表用户访问自己的数据。Internet上几乎所有受保护的资源都是以WebAPI的形式访问的。我们说OAuth2.0是和安全相关的，用来保护webAPI的。另外，第三方软件通过OAuth2.0获得访问权限后，用户将这些权限委托给第三方软件。我们说OAuth2.0是委托协议，没有问题。业务应用系统作为统一认证管控平台的客户端，统一认证管控平台作为服务端，服务独立部署。减少安全风险的“攻击面”。版权声明：本文为博主原创文章，遵循相关版权协议。如需转载或分享，请附上原文出处链接和链接出处。
