IdentityServer概念篇(OAuth2.0)

引子

在学习eShopOnContainers微服务架构的时候，不得不提到IdentityServer（身份认证服务器）：

 

 所有的客户端先从标识微服务获取令牌，然后请求时携带令牌完成认证。

下面我们就来学习关于IdentityServer相关概念，到写作目前为止，IdentityServer发展到v4，也就是IdentityServer4:

• IdentityServer是由一系列包组成的开源框架， 
• 它实现了OpenID Connect 和 OAuth 2.0 协议，
• IdentityServer是将规范兼容的OpenID Connect和OAuth 2.0端点添加到任意ASP.NET Core应用程序的中间件(middleware)和依赖服务(services)。

所以学习IdentityServer之前，就需要理解什么是OAuth2.0，下面通过生活中的场景延申到互联网场景： 

 

生活中的场景——快递员进小区

 转自 OAuth 2.0 的一个简单解释：

场景需求

 我住在一个大型的居民小区，小区有门禁系统。

进入的时候需要输入密码。

我经常网购和外卖，每天都有快递员来送货。我必须找到一个办法，让快递员通过门禁系统，进入小区。

如果我把自己的密码，告诉快递员，他就拥有了与我同样的权限，这样好像不太合适。万一我想取消他进入小区的权力，也很麻烦，我自己的密码也得跟着改了，还得通知其他的快递员。

有没有一种办法，让快递员能够自由进入小区，又不必知道小区居民的密码，而且他的唯一权限就是送货，其他需要密码的场合，他都没有权限？

授权机制的设计

于是，我设计了一套授权机制。

第一步，门禁系统的密码输入器下面，增加一个按钮，叫做"获取授权"。快递员需要首先按这个按钮，去申请授权。

第二步，他按下按钮以后，屋主（也就是我）的手机就会跳出对话框：有人正在要求授权。系统还会显示该快递员的姓名、工号和所属的快递公司。

我确认请求属实，就点击按钮，告诉门禁系统，我同意给予他进入小区的授权。

第三步，门禁系统得到我的确认以后，向快递员显示一个进入小区的令牌（access token）。令牌就是类似密码的一串数字，只在短期内（比如七天）有效。

第四步，快递员向门禁系统输入令牌，进入小区。

有人可能会问，为什么不是远程为快递员开门，而要为他单独生成一个令牌？这是因为快递员可能每天都会来送货，第二天他还可以复用这个令牌。另外，有的小区有多重门禁，快递员可以使用同一个令牌通过它们。

令牌与密码的比较

令牌（token）与密码（password）的作用是一样的，都可以进入系统，但是有三点差异。

（1）令牌是短期的，到期会自动失效，用户自己无法修改。密码一般长期有效，用户不修改，就不会发生变化。

（2）令牌可以被数据所有者撤销，会立即失效。以上例而言，屋主可以随时取消快递员的令牌。密码一般不允许被他人撤销。

（3）令牌有权限范围（scope），比如只能进小区的二号门。对于网络服务来说，只读令牌就比读写令牌更安全。密码一般是完整权限。

上面这些设计，保证了令牌既可以让第三方应用获得权限，同时又随时可控，不会危及系统安全。这就是 OAuth 2.0 的优点。

注意，只要知道了令牌，就能进入系统。系统一般不会再次确认身份，所以令牌必须保密，泄漏令牌与泄漏密码的后果是一样的。 这也是为什么令牌的有效期，一般都设置得很短的原因。

 

互联网中的场景——第三方网站访用户在Google的照片

 转自 理解OAuth 2.0：

 有一个"云冲印"的网站，可以将用户储存在Google的照片，冲印出来。用户为了使用该服务，必须让"云冲印"读取自己储存在Google上的照片。

 

问题是只有得到用户的授权，Google才会同意"云冲印"读取这些照片。那么，"云冲印"怎样获得用户的授权呢？

传统方法是，用户将自己的Google用户名和密码，告诉"云冲印"，后者就可以读取用户的照片了。这样的做法有以下几个严重的缺点。

（1）"云冲印"为了后续的服务，会保存用户的密码，这样很不安全。

（2）Google不得不部署密码登录，而我们知道，单纯的密码登录并不安全。

（3）"云冲印"拥有了获取用户储存在Google所有资料的权力，用户没法限制"云冲印"获得授权的范围和有效期。

（4）用户只有修改密码，才能收回赋予"云冲印"的权力。但是这样做，会使得其他所有获得用户授权的第三方应用程序全部失效。

（5）只要有一个第三方应用程序被破解，就会导致用户密码泄漏，以及所有被密码保护的数据泄漏。

OAuth就是为了解决上面这些问题而诞生的，OAuth 的核心就是向第三方应用颁发令牌。

 

结合上面的场景，在现代互联网应用中，有基于浏览器的传统网页应用，有基于微信的公众号、小程序，基于IOS、Android的native App，还有基于Windows系统的桌面Legacy应用和UWP应用等等，这么多种类的应用，后端服务也在不断向微服务架构方向演进， 考虑各个应用之间的交互，后端微服务之间的通信，其中身份的认证和授权就是每个应用及服务必不可少的的一部分，提炼出的通用协议就是OpenID Connect和OAuth， 提炼出的通用模块就是我们要说的IdentityServer4。

 

 

 

术语(Terminology/Concept)

 

  

 

让我们结合上面的图例上下文来解释相关术语：

IdentityServer

IdentityServer 是一个OpenID Connect提供程序，它实现了OpenID Connect 和 OAuth 2.0 协议。
同样的角色，不同的文档使用不同的术语。在有些文档中，它（IdentityServer）可能会被叫做安全令牌服务器（security token service）、身份提供者（identity provider）、授权服务器（authorization server）、 标识提供方（(IP-STS，什么是IP-STS）等等。但是它们都是一样的，都是向客户端发送安全令牌（security token）。
IdentityServer有许多功能：

 

 从部署角度说，IdentityServer（Authorization endPoint 和Token Endpoint）可以和被保护的web应用部署在统一台服务器上，也可以部署在单独的服务器上。

 

用户(User)

也即资源所有者(Resource Owner)， A user is a human that is using a registered client to access resources

 

客户端（Client/Third Party application）

客户端是从IdentityServer请求令牌的软件，用于验证用户（请求身份令牌）或访问资源（请求访问令牌）。 
客户端可以是Web应用程序，本地移动或桌面应用程序(WPF)，SPA，服务器进程(console app)等。
比如上面场景中的”云冲印“网站。

 

必须首先向IdentityServer注册客户端才能请求令牌(AddInMemoryClients(InMemoryConfiguration.GetClients())

IIdentityServerBuilder.AddInMemoryClients(IEnumerable<Client> clients)

 

资源（Resources）

资源是您想要保护的资源 ，两种最基本的资源类型：

• API资源，表示客户端想要调用的功能 ，通常被建模为Web API，但不一定。
• 用户身份数据标识信息(Identity Data，aka Claims)，比如姓名或邮件地址等。

资源部署在Resource server（资源服务器），即服务提供商存放用户生成的资源的服务器。它与认证服务器，可以是同一台服务器，也可以是不同的服务器。

 

引用

• IdentityServer4 官网
• 阮一峰老师：理解OAuth 2.0 & OAuth 2.0 教程

 

 

* 文档声明：自由转载-非商用-非衍生-保持署名（创意共享3.0许可证）