OAuth2.0 简介

By:Somnus陈

Windows Server 201默认的最大远程登录连接为2个，超过这个数目需要使用license server进行授权，但又给予你120天的使用时间，如果在这个时间之内没有配置授权，就会出现下面这个问题
1、安装角色和功能。
第一要安装角色功能，服务器管理器 > 添加角色和功能 > 安装如下几个选项，远程桌面代理可以不安装。只要嗯那个出现右边那些就是OK的。
2的配置：查看资源授权策略
属性：

3、激活远程桌面授权服务器
这部分省略了，主要是图太多，自行百度吧
提醒一点，就算激活服务器了，但是你用远程桌面授权诊断程序去测试的时候会告诉你有些还没有配置。
里面有三个选项，这里需要配置两个，配置完成之后回去再刷新，错误就没了。
第一个：使用指定的远程桌面许可证服务器。
第二个：设置远程授权模式。

背景

首先token认证方式的出现是伴随着系统架构的发展而来的。

最初的单机应用使用sessionId+cookie完全可以满足问题。

随着系统业务访问量加大，为满足服务高可用需求，系统引入了分布式架构，但是session只能存在单机节点上，为了解决这一问题，首先使用过 session粘贴 技术（通过hash等手段让请求始终访问之前生成sessionId的节点），这个方案的问题是万一存sessionId的节点挂了，整个系统都不能登陆了，也违背了高可用的设计思路；后来使用 session复制 的方案，即每台节点都copy一份sessionId，这引出2个问题，第一个就是分布式一致性的问题，节点同一时间重复创建了怎么办？另一个就是更头疼的系统扩展问题，随着系统越来越庞大，节点增多，session复制消耗的性能也越来越大，整个系统因为session出现了可遇见的性能瓶颈；再后来出现了session集中存储到一个地方，这样解放了服务器，但是session存储的高可用问题又来了，简直就是套娃式困局。

既然 有状态服务 出现瓶颈，大佬们开始提出 无状态服务 ，就是使用token验证方式替代较重的session，token就是一个字符串，只要服务根据约定好的算法解析出的结果跟预期一致就可以通过验证，也不需要保存在内存中，无状态服务的好处是系统扩展轻松，新追加的服务轻装上阵，完全没有顾虑。Oauth就是一种规范，用来保证token机制的可行，目前在web端和移动端都是主流登陆验证方案，Oauth20于2010年正式提出，一直沿用到现在，可见其稳定。

随着互联网行业迅猛发展，各种app，各种网站层出不穷，传统登陆方式就要求用户在每个想登陆的站点都要注册自己的账号信息和密码，这也留下了一定隐患，有的小站点可能技术不那么强，这就有可能导致用户信息泄漏，Oauth正好可以解决这种对一些站点即想用又不信任问题。从使用体验的角度，单点登陆的方式也可以简化用户对账号密码的管理。

Oauth2认证模式的4种类型

这种模式最常用，也是最安全的模式，相关的角色有3个：
客户端 （web站点/app，从认证服务的视角，不管你是web页面还是后台服务，都属于客户端范畴）、 资源服务 （存放个人信息的服务，比如微信存放你个人信息的服务）、 认证服务 （某可信的账户平台如微信平台）

使用之前需要在认证服务注册下自己的app信息（主要包括app名称、app站点、认证callback地址等），认证平台会给客户端创建一个clientId（客户端id）和client_secret（客户端秘钥）。这是为了解决认证平台不信任客户端的问题。

使用的时候用户首先会点击客户端登陆页上的一个链接，打开认证服务上的一个登陆确认页面，用户认证的时候会上传以下请求参数：

认证成功后，认证服务会重定向到redirect_uri,
同时认证服务还会按照之前注册好的callback地址，向客户端发一个get请求，参数：

这样客户端拿到了code，会再向认证平台的授权服务器发起请求，参数：

授权服务验证code没问题后，会给客户端返回token。

客户端拿着token就可以去资源服务器请求用户信息了（头像、姓名等）。

这种模式大致流程是：

这个模式不经过code验证的过程，这种token可以直接在callback的uri上看到，并且客户端后台也不会验证token，这种模式安全性显然没有授权码模式好，应用也不多。

流程：
用户直接在客户端上输入账号密码，然后由客户端向认证服务请求要token。

要使用这种模式就表明用户完全信任客户端了，如果信任客户端，直接在客户端上注册账号不就好了，何必把其他平台的账号告诉客户端，万一客户端保存了这个账号密码呢？

流程：
用客户端自己的名义向认证服务获取token，跟用户没什么关系。这也不会是登陆会考虑的场景吧

>