dex

具有可插拔连接器的 OpenID 连接身份(OIDC)和 OAuth 2.0 提供商。「OpenID Connect Identity (OIDC) and OAuth 2.0 Provider with Pluggable Connectors」

Github星跟蹤圖

dex -- 一个联合的OpenID连接提供商

具有可插拔连接器的 OpenID Connect Identity(OIDC)和 OAuth 2.0 提供程序

Dex 是一种身份服务,它使用 OpenID Connect 来驱动其他应用程序的认证。

Dex 通过 "连接器" 充当其他身份提供商的门户。这让 dex 可以将身份验证推迟到 LDAP 服务器、SAML 提供商或 GitHub、Google 和 Active Directory 等成熟的身份提供商。客户端只需写一次认证逻辑就可以与 dex 交谈,然后 dex 就可以处理特定后端的协议。

ID 令牌

ID 令牌是由 OpenID Connect 引入的 OAuth2 扩展,也是 dex 的主要功能。ID 令牌是由 dex 签署的 JSON 网络令牌(JWT),并作为 OAuth2 响应的一部分返回,以证明最终用户的身份。一个 JWT 的例子可能是这样的。

eyJhbGciOiJSUzI1NiIsImtpZCI6IjlkNDQ3NDFmNzczYjkzOGNmNjVkZDMyNjY4NWI4NjE4MGMzMjRkOTkifQ.eyJpc3MiOiJodHRwOi8vMTI3LjAuMC4xOjU1NTYvZGV4Iiwic3ViIjoiQ2djeU16UXlOelE1RWdabmFYUm9kV0kiLCJhdWQiOiJleGFtcGxlLWFwcCIsImV4cCI6MTQ5Mjg4MjA0MiwiaWF0IjoxNDkyNzk1NjQyLCJhdF9oYXNoIjoiYmk5NmdPWFpTaHZsV1l0YWw5RXFpdyIsImVtYWlsIjoiZXJpYy5jaGlhbmdAY29yZW9zLmNvbSIsImVtYWlsX3ZlcmlmaWVkIjp0cnVlLCJncm91cHMiOlsiYWRtaW5zIiwiZGV2ZWxvcGVycyJdLCJuYW1lIjoiRXJpYyBDaGlhbmcifQ.OhROPq_0eP-zsQRjg87KZ4wGkjiQGnTi5QuG877AdJDb3R2ZCOk2Vkf5SdP8cPyb3VMqL32G4hLDayniiv8f1_ZXAde0sKrayfQ10XAXFgZl_P1yilkLdknxn6nbhDRVllpWcB12ki9vmAxklAr0B1C4kr5nI3-BZLrFcUR5sQbxwJj4oW1OuG6jJCNGHXGNTBTNEaM28eD-9nhfBeuBTzzO7BKwPsojjj4C9ogU4JQhGvm_l4yfVi0boSx8c0FX3JsiB0yLa1ZdJVWVl9m90XmbWRSD85pNDQHcWZP9hR6CMgbvGkZsgjG32qeRwUL_eNkNowSBNWLrGNPoON1gMg

ID 令牌包含标准声明,申明哪个客户端应用登录了用户,令牌何时过期,以及用户的身份。

{
  "iss": "http://127.0.0.1:5556/dex",
  "sub": "CgcyMzQyNzQ5EgZnaXRodWI",
  "aud": "example-app",
  "exp": 1492882042,
  "iat": 1492795642,
  "at_hash": "bi96gOXZShvlWYtal9Eqiw",
  "email": "jane.doe@coreos.com",
  "email_verified": true,
  "groups": [
    "admins",
    "developers"
  ],
  "name": "Jane Doe"
}

由于这些令牌由 dex 签署,并包含基于标准的声明,其他服务可以将其作为服务对服务的凭证来使用。已经可以使用 dex 发行的 OpenID Connect ID 令牌的系统包括:

有关如何请求或验证 ID Token 的详细信息,请参见 "编写使用 dex 的应用程序"

Kubernetes + dex

Dex 的主要生产用途是作为 CoreOS 企业级 Kubernetes 解决方案 Tectonic 中的 auth-N 插件。Dex 使用第三方资源原生运行在任何 Kubernetes 集群之上,并可以通过OpenID Connect插件驱动API服务器认证。客户端,如 Tectonic Console 和 kubectl,可以代表用户通过 dex 支持的任何身份提供者登录集群。

更多关于 dex 作为 Kubernetes 身份验证器运行的文档可以在这里找到。

连接器

当用户通过 dex 登录时,用户的身份通常存储在另一个用户管理系统中:LDAP 目录、GitHub org 等。Dex 在客户端应用和上游身份提供者之间起到了一个垫片的作用。客户端只需要了解 OpenID Connect 就可以查询 dex,而 dex 则实现了一系列协议来查询其他用户管理系统。

"connector" 是 dex 使用的一种策略,用于针对另一个身份提供者进行用户认证。Dex 实现了针对 GitHub、LinkedIn 和微软等特定平台的连接器,以及 LDAP 和 SAML 等成熟协议。

根据连接器的不同,协议中的限制可能会阻止 dex 发出刷新令牌或返回组成员资格声明。例如,由于 SAML 没有提供非交互式的方式来刷新断言,如果用户通过 SAML 连接器登录,dex 就不会向其客户端发出刷新令牌。对于需要离线访问的客户端,如 kubectl,需要刷新令牌支持。

Dex 实现了以下连接器:

Name supports refresh tokens supports groups claim supports preferred_username claim status notes
LDAP yes yes yes stable
GitHub yes yes yes stable
SAML 2.0 no yes no stable
GitLab yes yes yes beta
OpenID Connect yes yes yes beta Includes Salesforce, Azure, etc.
Google yes yes yes alpha
LinkedIn yes no no beta
Microsoft yes yes no beta
AuthProxy no no no alpha Authentication proxies such as Apache2 mod_auth, etc.
Bitbucket Cloud yes yes no alpha
OpenShift no yes no stable
Atlassian Crowd yes yes yes * beta preferred_username claim must be configured through config
Gitea yes no yes alpha

稳定版、beta 版和 alpha 版的定义是:

  • 稳定版:经过良好的测试,正在使用中,不会以不兼容的方式向后改变。
  • Beta:经过测试,不可能以向后不兼容的方式改变。
  • Alpha:可能未经过核心维护者的测试,并且会以向后不兼容的方式进行更改。

所有连接器功能的更改或废止将在发布说明中公布。

文档

报告安全漏洞

由于其公开的性质,GitHub 和邮件列表不是报告漏洞的适当地方。当报告可能与安全有关的问题时,请参考 CoreOS 的安全披露程序。

获得帮助

  • 对于功能请求和错误,请提交一个问题
  • 对于使用和开发dex的一般性讨论,你可以加入 Kubernetes Slack 上的 #dexidp 频道,或者加入 dex-dev 邮件列表。


(The first version translated by vz on 2020.10.15)

概覽

名稱與所有者dexidp/dex
主編程語言Go
編程語言Go (語言數: 7)
平台Amazon AWS, Docker, Kubernetes, Linux, Mac, Windows
許可證Apache License 2.0
發布數84
最新版本名稱v2.39.0 (發布於 )
第一版名稱v0.1.0 (發布於 )
創建於2015-08-17 17:57:06
推送於2024-03-26 09:20:23
最后一次提交2024-03-22 21:16:21
星數8.9k
關注者數173
派生數1.6k
提交數2.8k
已啟用問題?
問題數1099
打開的問題數293
拉請求數1459
打開的拉請求數116
關閉的拉請求數532
已啟用Wiki?
已存檔?
是復刻?
已鎖定?
是鏡像?
是私有?

dex - A federated OpenID Connect provider

GitHub Workflow Status
Go Report Card
GoDoc

logo

Dex is an identity service that uses [OpenID Connect][openid-connect] to drive authentication for other apps.

Dex acts as a portal to other identity providers through "connectors." This lets dex defer authentication to LDAP servers, SAML providers, or established identity providers like GitHub, Google, and Active Directory. Clients write their authentication logic once to talk to dex, then dex handles the protocols for a given backend.

ID Tokens

ID Tokens are an OAuth2 extension introduced by OpenID Connect and dex's primary feature. ID Tokens are [JSON Web Tokens][jwt-io] (JWTs) signed by dex and returned as part of the OAuth2 response that attest to the end user's identity. An example JWT might look like:

eyJhbGciOiJSUzI1NiIsImtpZCI6IjlkNDQ3NDFmNzczYjkzOGNmNjVkZDMyNjY4NWI4NjE4MGMzMjRkOTkifQ.eyJpc3MiOiJodHRwOi8vMTI3LjAuMC4xOjU1NTYvZGV4Iiwic3ViIjoiQ2djeU16UXlOelE1RWdabmFYUm9kV0kiLCJhdWQiOiJleGFtcGxlLWFwcCIsImV4cCI6MTQ5Mjg4MjA0MiwiaWF0IjoxNDkyNzk1NjQyLCJhdF9oYXNoIjoiYmk5NmdPWFpTaHZsV1l0YWw5RXFpdyIsImVtYWlsIjoiZXJpYy5jaGlhbmdAY29yZW9zLmNvbSIsImVtYWlsX3ZlcmlmaWVkIjp0cnVlLCJncm91cHMiOlsiYWRtaW5zIiwiZGV2ZWxvcGVycyJdLCJuYW1lIjoiRXJpYyBDaGlhbmcifQ.OhROPq_0eP-zsQRjg87KZ4wGkjiQGnTi5QuG877AdJDb3R2ZCOk2Vkf5SdP8cPyb3VMqL32G4hLDayniiv8f1_ZXAde0sKrayfQ10XAXFgZl_P1yilkLdknxn6nbhDRVllpWcB12ki9vmAxklAr0B1C4kr5nI3-BZLrFcUR5sQbxwJj4oW1OuG6jJCNGHXGNTBTNEaM28eD-9nhfBeuBTzzO7BKwPsojjj4C9ogU4JQhGvm_l4yfVi0boSx8c0FX3JsiB0yLa1ZdJVWVl9m90XmbWRSD85pNDQHcWZP9hR6CMgbvGkZsgjG32qeRwUL_eNkNowSBNWLrGNPoON1gMg

ID Tokens contains standard claims assert which client app logged the user in, when the token expires, and the identity of the user.

{
  "iss": "http://127.0.0.1:5556/dex",
  "sub": "CgcyMzQyNzQ5EgZnaXRodWI",
  "aud": "example-app",
  "exp": 1492882042,
  "iat": 1492795642,
  "at_hash": "bi96gOXZShvlWYtal9Eqiw",
  "email": "jane.doe@coreos.com",
  "email_verified": true,
  "groups": [
    "admins",
    "developers"
  ],
  "name": "Jane Doe"
}

Because these tokens are signed by dex and [contain standard-based claims][standard-claims] other services can consume them as service-to-service credentials. Systems that can already consume OpenID Connect ID Tokens issued by dex include:

  • [Kubernetes][kubernetes]
  • [AWS STS][aws-sts]

For details on how to request or validate an ID Token, see ["Writing apps that use dex"][using-dex].

Kubernetes + dex

Dex's main production use is as an auth-N addon in CoreOS's enterprise Kubernetes solution, [Tectonic][tectonic]. Dex runs natively on top of any Kubernetes cluster using Third Party Resources and can drive API server authentication through the OpenID Connect plugin. Clients, such as the [Tectonic Console][tectonic-console] and kubectl, can act on behalf users who can login to the cluster through any identity provider dex supports.

More docs for running dex as a Kubernetes authenticator can be found here.

Connectors

When a user logs in through dex, the user's identity is usually stored in another user-management system: a LDAP directory, a GitHub org, etc. Dex acts as a shim between a client app and the upstream identity provider. The client only needs to understand OpenID Connect to query dex, while dex implements an array of protocols for querying other user-management systems.

A "connector" is a strategy used by dex for authenticating a user against another identity provider. Dex implements connectors that target specific platforms such as GitHub, LinkedIn, and Microsoft as well as established protocols like LDAP and SAML.

Depending on the connectors limitations in protocols can prevent dex from issuing [refresh tokens][scopes] or returning [group membership][scopes] claims. For example, because SAML doesn't provide a non-interactive way to refresh assertions, if a user logs in through the SAML connector dex won't issue a refresh token to its client. Refresh token support is required for clients that require offline access, such as kubectl.

Dex implements the following connectors:

去到頂部