标签：
今天推荐的是我一直以来都在关注的一个开源的OpenID Connect/OAuth 2.0服务框架——IdentityServer3。其支持完整的OpenID Connect/OAuth 2.0标准，使用它就可以轻易地搭建一个单点登录服务器。
说是一直关注，是因为1年前，要为一个平台搭建一个OAuth 2.0服务器，当时由于IdentityServer3还处于开发阶段，核心还不稳定，扩展功能也不完备。无奈只好熟读OAuth 2.0的规范，并根据www.asp.net网站上的一个简单示例自己实现了一个。不过现在好了，IdentityServer3在今年初正式发布稳定的1.0版本。注：IdentityServer3的开发商之前就有IdentityServer2的产品，不过是IdentityServer3基于微软最新的ASP.NET技术（比如OWIN等思想），以中间件的形式出现，更具扩展性。
为什么会出现IdentityServer3这样的框架呢？现代应用程序或多或少都是如下这样的架构：
在这种情况下，前端、中间层和后端都需要进行验证和授权来保护资源，所以不能仅仅在业务逻辑层或者服务接口层来实现基础的安全功能。为了解决这样的问题，通常就会导致如下安全架构：
上图其实是把整个安全问题分解为两个方面：验证和API访问。
所谓验证，就是应用程序需要知道当前用户是谁。通常应用程序都会管理用户信息，并代表用户来访问用户被授权的资源。这对于典型的Web应用程序很常见，但是对于原生应用程序或基于JS的应用程序也是需要验证。所以业界就制定了各种各样的通用验证协议：SAML2p、WS-Federation和OpenID Connect。SAML2p之前运用的比较广泛，不过作为后起之秀的OpenID Connect（其本质是基于OAuth 2.0扩展而来）对现代的应用程序（尤其移动应用）而言更加适合。
对于API访问。应用程序有两种方式来和API进行通信：使用应用程序自己的标识，或者代表用户使用用户的标识。OAuth2协议就允许应用程序先从安全令牌服务哪里请求一个访问令牌，然后随后用这个令牌来和API进行通信（API会访问令牌服务器来验证访问者的令牌是否有效）。这就降低了客户应用程序和API之间的复杂度，因为验证和授权都被中心化了。
由于OpenID Connect和OAuth 2.0非常类似，所以IdentityServer3的目标就是同时支持两者。其支持如下的标准：
IdentityServer3作为一个框架，具有很多扩展点（见官方文档Service Factory章节），也附带了很多扩展包：
最后想谈谈我们是否应该把这样的框架用于我们产品（尤其在比较关键的安全相关功能）中，也即是否应该“重复制造轮子”的问题。
在我看来，“我们可以重复创造自己的汽车，但是绝对不要重复制造轮子”。尤其对于初创的小团队更是如此，小团队应该把精力用于快速验证业务可行性上。首先，你无法保证在制造轮子这件事情上比其他人（比如IdentityServer3的开发者一直都是做验证框架和服务器的）更专业；其次，你制造的轮子维护性肯定比现成的轮子更难（除非你打算自造轮子的原因就是有私心让别人无法接手），也比现成的轮子学习成本更难（团队其他成员无法快速地基于现有文档快速入手）；最后，现成的轮子就算有欠缺，那么正确的态度是参与开源项目来完善它促进社区发展，而不是因噎废食。
“阅读原文”是IdentityServer3的官方文档目录。可以先通读文档后，来判断是否用于自己的产品。
原文地址：http://identityserver.github.io/Documentation/docs/
一个功能完备的.NET开源OpenID Connect/OAuth 2.0框架——IdentityServer3
标签：
原文地址：http://www.cnblogs.com/redmoon/p/4448968.html
