如何使用dex搭建一个身份认证系统？

导言

一个成熟的软件系统一般必须有一个可靠的身份认证与权限验证功能。这一块要自研快速实现还是需要花费挺多精力的，幸好开源领域目前已经有不错的解决方案，一般拿过来按项目的实际需求进行一些简单的定制基本就可以实现业务目标了。最近刚好在这方面进行了一些工作，这里将如何实现身份认证及权限验证分两篇博文大概梳理一下，这篇先讲身份认证。

什么是身份认证

身份验证（英语：Authentication）又称“验证”，是指通过一定的手段，完成对用户身份的确认。

身份验证的目的是确认当前所声称为某种身份的用户，确实是所声称的用户。在日常生活中，身份验证并不罕见；比如，通过检查对方的证件，我们一般可以确信对方的身份。虽然日常生活中的这种确认对方身份的做法也属于广义的“身份验证”，但“身份验证”一词更多地被用在计算机、通信等领域。

以上是维基百科的解释，说白了就是用某种方式确保用户是某种身份，这种确保需要保证其它用户没那么容易伪装其身份。一般只有经过身份认证得到可靠的用户身份后，才能基于该身份进行后续的权限验证流程。

实现身份认证系统

一般来说业务系统会专注于业务逻辑的处理，而身份认证相关的功能会放入独立的身份认证系统进行开发维护。要纯自研地完成一套可靠、安全度高的身份认证系统还是比较花费精力的，幸好开源领域目前已经有不错的解决方案，一般拿过来按项目的实际需求进行一些简单的定制基本就可以实现业务目标了。我这里的示例使用dex实现了一个简单的用户认证系统

——https://github.com/jeremyxu2010/demo-dex

运行示例

前提是已经搭建好了go语言的开发环境，并设置好了GOPATH。

然后按以下步骤运行本程序：

然后用浏览器访问http://127.0.0.1:8080, 页面会自动跳转至dexserver的登录页面，输入用户名admin@example.com、密码password之后，会跳回dexclient的callback页面http://127.0.0.1:8080/callback。

示例的技术细节

dexserver

这里使用的dexserver是由官方代码直接编译得出的，没有修改任何代码。只不过使用了自定义的配置文件dexserver-config.yaml，这里分析一下这个配置文件。

（点击查看大图）

web段配置的是dexserver的监听地址及HTTPS证书参数，issuer配置的是外部会访问到的系统URL，这两者一般要对应地设置。

telemetry段配置的是监控指标抓取地址，本例中dexserver启动完毕后，可访问——http://127.0.0.1:5558/metrics抓取到该dexserver的监控指标。

storage段配置的是dexserver的存储设置。dexserver在运行时跟踪refresh_token、auth_code、keys、password等的状态，因此需要将这些状态保存下来。dex提供了多种存储方案，如etcd、CRDs、SQLite3、Postgres、MySQL、memory，总有一款能满足需求。如果要其它需求，还可以参考现有Storage:

https://github.com/dexidp/dex/tree/master/storage

以及文档扩展:

https://github.com/dexidp/dex/blob/master/Documentation/storage.md#adding-a-new-storage-options

我这里使用的是比较简单的SQLite3Storage，提前插入了一条测试的用户数据：

123	sqlite3 config/dex.dbsqlite> insert info password values('admin@example.com', '$2a$10$2b2cU8CPhOTaGrs1HRQuAueS7JTT5ZHsHSzYiFPm1leZck7Mc8T4W', 'admin', '08a8684b-db88-4b73-90a9-3cd1661f5466');sqlite> .quit

oauth2.skipApprovalScreen这个选项我设置成了true，这样就不会有提示用户同意的页面出现。

staticClients段配置的是该dexserver允许接入的dexclient信息，这个要跟dexclient那边的配置一致。

connectors段我并没有配置任何Connector。Connector是dex中一项重要特性，其可以将dex这个身份认证系统与其它身份认证系统串联起来。dex目前自带的Connector有LDAP、GitHub、SAML 2.0、GitLab、OpenID Connect、LinkedIn、Microsoft、AuthProxy、Bitbucket Cloud，基本上满足绝大部分需求，如果要扩展，参考某个现成的Connector:

https://github.com/dexidp/dex/tree/master/connector实现即可。

我这个示例里因为直接使用保存在DB里的帐户密码信息，因此只需要配置enablePasswordDB为true，就会自动使用上passwordDB这个Connector。passwordDB的实现代码见：

https://github.com/dexidp/dex/blob/master/server/server.go#L325

最近由于登录页面是由dexserver提供了，这里还将dex自带的登录页面web端资源带上了，具体的项目中根据场景对页面进行一些定制就可以了。

dexclient

dexclient就很简单了，就两个go文件，重点是cmd/dexclient/main.go。

首先是根据一系列参数构造出oidc.Provider及oidc.IDTokenVerifier，这个后面获取认证系统的跳转地址、获取id_token、校验id_token都会用到:

123	...a.provider = providera.verifier = provider.Verifier(&oidc.Config{ClientID: a.clientID})

然后声明处理三个请求地址，并启动Web Server：

1234567891011121314	http.HandleFunc("/", a.handleIndex) http.HandleFunc("/login", a.handleLogin) http.HandleFunc(u.Path, a.handleCallback)switch listenURL.Scheme

很明显handleIndex就是WEB应用的主页，这里一般逻辑应该是检查用户的登录身份信息是否合法，如果不合法则跳至dexserver的登录页面。

handleLogin根据浏览器发来的cross_client、extra_scopes、connector_id、offline_access参数构造出登录页跳转地址，并提示浏览器跳至该地址:

1234567891011121314

...if r.FormValue("offline_access") != "yes" { authCodeURL = a.oauth2Config(scopes).AuthCodeURL(exampleAppState) } else if a.offlineAsScope { scopes = append(scopes, "offline_access") authCodeURL = a.oauth2Config(scopes).AuthCodeURL(exampleAppState) } else { authCodeURL = a.oauth2Config(scopes).AuthCodeURL(exampleAppState, oauth2.AccessTypeOffline) }if connectorID != "" { authCodeURL = authCodeURL + "&connector_id=" + connectorID } http.Redirect(w, r, authCodeURL, http.StatusSeeOther)

handleCallback处理登录成功后的回调请求，其根据回调请求中的code参数，调用dexserver的相关接口换取包含用户身份信息的Token：

12345678910	code := r.FormValue("code")if code == "" { http.Error(w, fmt.Sprintf("no code in request: %q", r.Form), http.StatusBadRequest)return }if state := r.FormValue("state"); state != exampleAppState { http.Error(w, fmt.Sprintf("expected state %q got %q", exampleAppState, state), http.StatusBadRequest)return } token, err = oauth2Config.Exchange(ctx, code)

一般来说，会将该Token中的id_token进行适当的编码发回到浏览器中保存（以Cookie或WebStorage等方式），这样浏览器中就保存了用户的身份信息。

安全起见，dexserver签发的id_token有效期通常不会太长，这就需要dexclient凭借Token中的refresh_token隔段时间重新换取新的Token，并通过某种机制将新Token中的id_token重新发回浏览器端保存。以refresh_token重新换取新的Token的代码实现如下：