dexidp/dex部署及应用

October 24, 2023

 

简介

阅读pocketbase源码时其授权流程比较感兴趣，但pocketbase代码量太大了，授权部分并不是一个独立的模块。之前也看了kratos文档，感觉太过庞大，形态一套自己的生态体系。今天刚好看到了dex的介绍，预览了一下用法和代码仓库，感觉复杂度居中，而且能力不差。所以研究了一下其用法。

功能：降低app开发者实现Identifier provider对接的成本，可以通过Dex来快速实现各类provider的对接。

当用户通过dex进行登陆时，用户的身份信息通常存放在第三方用户管理系统中，例如LDAP。Dex作为客户端和第三方用户管理系统之间的垫片，其价值是，客户端仅仅需要理解OIDC，后端用户管理系统可以随时切换。

用法

Demo演示

  1. 启动Dex server
Loading...

可见到Dex Server已经在5556端口启动。相关配置可见config-dev.yaml。重点配置项解释：

  • storage：存储token等信息。支持SQLite、Mysql、PG等。详见：https://dexidp.io/docs/storage/
  • web：http监听地址，支持tls
  • telemetry： 监控上报
  • connectors：上游的IdP（upstream identity provider）。当用户通过Dex登录时，用户的身份通常存储在另一个用户管理系统（LDAP目录，GitHub组织等）中。Dex充当客户端应用程序和上游身份提供者之间的桥梁。客户端只需要了解OpenID Connect来查询Dex，而Dex实现了一系列协议来查询其他用户管理系统。支持的connector列表详见：https://dexidp.io/docs/connectors/
  • staticClients：app配置，dex可以针对不同的app下发不同的token。详见：https://dexidp.io/docs/custom-scopes-claims-clients/#cross-client-trust-and-authorized-party
  1. 启动应用服务Example-App，验证完整流程。
Loading...

然后就可以体验基础流程了，见下方流程图

流程介绍

  • browser → localhost:5555/index: 业务方功能页，提供跳转到登录页的入口
  • browser → localhost:5555/login：用户点击登录，业务方登录后台拼接Dex授权页面的地址，以及授权完毕后的callback地址，返回给browser执行跳转。核心参数：
    • extra_scopes：需要授权的scope信息，支持的scope列表包括openid、email、profile等。
    • cross_client：app名称，在dex server的配置文件下staticClients已登记。
    • connector_id：对应到dex server支持的connector id，详见上面的config-dev.yaml配置。
  • browser → localhost:5556/dex/auth：跳转到dex的登录页，demo中使用的是mock provider。需要输入密码完成登录、授权操作。
  • dex server会返回授权完毕后的callback地址，并携带code、state给到页面。供跳转使用
  • browser → localhost:5555/callback，业务方后台获取到code，从dex server换取JWT token、accesstoken等票据，完成整体流程。换取token请求：
Loading...
  • dex server中也会存储相关票据，供业务后续使用。
Loading...

整体流程比较简单，如果需要在项目中使用大约要做几个事情：

  1. 部署Dex server，以及对应的存储方案选择等。大型项目需要考虑mysql、PG、etcd等存储方案。因为还需要业务方的鉴权请求，这比授权的量要大上数倍
  2. 开发对应的登录页。demo中的登录页比较简单，业务方的登录页需要适配业务形态，如增加用户协议、选择账号类型（connector）等。
  3. 开发对应的callback页、后台。功能包括票据换取，跳转到登录之前的原始功能页等。

Reference

See all postsSee all posts