转载

dex, CoreOS发布的一个开源的OpenID Connect身份服务

今天我们兴奋的发布CoreOS家族一个新的开源项目 dex : 一个基于多种标准的身份服务提供者和认证解决方案。

几乎每一个项目都需要某种认证和用户管理。应用也需要一种方式能让用户从多种平台安全地登录，例如web，移动端，命令行工具（CLI)，以及自动化系统等。开发者通常使用一个依赖于平台的解决方案，或者当常常发现现有的解决方案没法很好的解决他们的需求后就自己从头写一个解决方案。

然而，大多数开发者并不在安全相关的业务中。让他们自己写认证软件不仅会让他们从核心产品的开发工作中分心，同时也显然会带来软件安全方面的危险。正确的处理安全方面的工作是很有难度的，我们最近看到很多引人注目的安全事故，在没有被其他工程师或者安全专家做恰当审计的情况下任意而为只会带来更多的风险。

正是基于这些原因，我们决定开源dex，这样我们已经完成的让dex成为一个安全健壮的平台的工作会让其他人也能受益。开放给社区之后，dex反过来也会从更多的合作者中受益。没有人再需要自己写一遍“忘记密码？”的流程，或者“以X，Y或者Z来登录”的功能了。

项目起名为‘dex’是因为它是一个中心化的用户索引，软件里面其他组件可以基于dex做认证。

核心设计元素

dex如此独特是它包含了以下这些元素，这些元素从最开始就驱动着设计和实现：

安全

安全是首要的工作： dex的设计采用了安全和加密的最佳实践来最小化攻击者获得系统访问权限的风险。更进一步， dex的架构划分也可以减轻任何单个攻击可能带来的损害。例如，dex缺省使用软token 生命周期，并自动轮换它的签名秘钥。由于秘钥本身是加密的，攻击者需要在短时间内同时侵入数据库和一个dex worker才能得到一个tocken。

标准

dex 是 OpenID Connect（OIDC）核心标准的实现. OIDC(不要与OpenID 混淆 )是由广泛的业界领袖和安全专家基于web安全领域的多年经验合作创建的. 它是OAuth2之上的一层，提供了一个安全并且易于实现的认证协议. 今天OIDC 已经作为一个单点登录的解决方案使用在众多internet巨头里，例如Google，Facebook， Amazon等。

语言与平台无关性

因为dex实现了 OpenID Connect(OIDC) Core Spec , 所以将dex集成中你的应用中十分简单. 仅需要一步: 加入你所用的编程语言的OIDC客户端库. 我们用Go写了一个 go-oidc ; 其他的几乎每种语言都有( 请审查对应的客户端库以保证有适当的签名验证和协议符合度).

联合身份

dex有自己的用户的概念, 但也允许通过不同的方式做认证, 称之为连接器 connector . 现在, dex自带了2种类型的连接器: 本地 local 连接器和OIDC 连接器. 当使用 local 连接器做认证时, 用户使用email和密码通过dex本身提供的定制化UI来登录; 当使用OIDC连接器时, 用户可以通过登录第三方的OIDC身份服务提供方来认证, 例如Goole或者Salesforce.

因为dex本身就是一个OIDC身份服务提供者, 它甚至可以做到将多个dex实例串联到一起,每个实例依次将认证工作委派给下一个.

现在用户必须在连接器中做选择,但是在未来我们计划允许身份的链接 linking , 这样每个单独的用户都可以以不同的方式登录. 可扩展的连接器架构将会允许与多种身份服务做集成,例如GitHub, LDAP, SAML系统等.

案例学习: Tectonic.com

在CoreOS我们正使用dex的一种方式是做 Tectonic 客户的注册和认证.当一个用户首次决定成为Tectonic客户并按下"Join"的按钮时, 他们会被带到 https://auth.tectoinc.com , 也就是OpenID Connect术语中的"Issuer URL". 他们可以使用自己的Google身份或者输入用户名密码来注册.然后他们会被重定向回Tectonic.com网站来完成注册.

下面的图描述了整个部署:

dex Infrastructure Diagram

在我们的防火墙之后,我们有如下几个组件:

一个postgres数据库用作dex的后端存储
一个单独的dex-overlord, 负责轮换秘钥和其他的管理任务
多个dex-worker, 提供前端给终端用户做认证
产品站点，Tectonic.com

在OIDC中的依赖方(Replying Party, RP)-此案例中, 即我们的产品站点-为了一个ID token, 与身份提供者(identity provider, IdP),也就是dex, 交换一个Authorization Token(从终端用户那得到, 这里是Tectnoic的用户). 注意虽然这里我们把我们的应用和dex都一起放在同一个防火墙后面, 但这并不是必须的. 他们互相之间是通过跨公网的一个TLS连接来沟通;如果你有多个不同的应用跑在不同的环境并都需要认证时这是相当有用的.

当用户选择使用Google账号做认证时, dex就临时变成RP, Google就变成了IdP来认证和识别用户. 一但dex完成了这个工作(通过上面提到的token交换协议), dex就回来成为IdP并完成与Tectonic.com的token交换.

整个过程中token都是加密签名过的,客户端会检查签名. 签名的秘钥会持续的被IdP来轮换并被RP来同步.