这是什么？
Dex 是一个身份服务，通过 OpenID Connect 为其他应用提供登录认证。借助可插拔的“连接器”（connector），它可以把登录委托给 LDAP、SAML 或 GitHub、Google 这类提供商，这样客户端只需写一次认证逻辑。
Dex 是一个身份服务，通过 OpenID Connect 为其他应用提供登录认证。借助可插拔的“连接器”（connector），它可以把登录委托给 LDAP、SAML 或 GitHub、Google 这类提供商，这样客户端只需写一次认证逻辑。那 dex 是一个完整的身份产品，还是我已有提供商前面的一层？它是一个联合认证的 OIDC 提供商：用户身份通常存放在上游的 LDAP 目录、GitHub 组织或 SAML 环境中，dex 充当你的应用与该提供商之间的中间层，签发客户端实际使用的已签名令牌（token）。
它是一个联合认证的 OIDC 提供商：用户身份通常存放在上游的 LDAP 目录、GitHub 组织或 SAML 环境中，dex 充当你的应用与该提供商之间的中间层，签发客户端实际使用的已签名令牌（token）。我怎样才能把 dex 跑起来？它是一个 Go 服务器：用 make 构建，或者运行官方发布的 Docker 镜像。README 指向官方文档，里面有入门、配置和使用指南。
它是一个 Go 服务器：用 make 构建，或者运行官方发布的 Docker 镜像。README 指向官方文档，里面有入门、配置和使用指南。它可以对接哪些身份提供商？15 个连接器：LDAP、GitHub、GitLab、Gitea、SAML 2.0、通用 OpenID Connect（覆盖 Salesforce、Azure 等类似提供商）、OAuth 2.0、Google、LinkedIn、Microsoft、AuthProxy、Bitbucket Cloud、OpenShift、Atlassian Crowd 和 OpenStack Keystone。
15 个连接器：LDAP、GitHub、GitLab、Gitea、SAML 2.0、通用 OpenID Connect（覆盖 Salesforce、Azure 等类似提供商）、OAuth 2.0、Google、LinkedIn、Microsoft、AuthProxy、Bitbucket Cloud、OpenShift、Atlassian Crowd 和 OpenStack Keystone。这些连接器都同样可靠吗？不是。每个连接器都分为 stable、beta 或 alpha 三个等级，功能也各不相同——比如 SAML 2.0 虽然是 stable 状态，却带有警告说明它无人维护，可能存在认证绕过漏洞。
不是。每个连接器都分为 stable、beta 或 alpha 三个等级，功能也各不相同——比如 SAML 2.0 虽然是 stable 状态，却带有警告说明它无人维护，可能存在认证绕过漏洞。dex 能跑在哪里——必须用 Kubernetes 吗？Kubernetes 是主打场景但并非必需：dex 通过 CRD 可以原生运行在任何集群上，并能通过 OIDC 插件接管 API 服务器的认证。kubectl 和 kubelogin 这类客户端随后就能代表通过任意已接入提供商登录的用户执行操作。
Kubernetes 是主打场景但并非必需：dex 通过 CRD 可以原生运行在任何集群上，并能通过 OIDC 插件接管 API 服务器的认证。kubectl 和 kubelogin 这类客户端随后就能代表通过任意已接入提供商登录的用户执行操作。登录成功后，应用实际能拿到什么？一个 ID Token——这是 dex 的核心功能。它是由 dex 签名的 JSON Web Token（JWT），带有标准声明（claims）：是哪个客户端应用为用户完成登录、令牌何时过期、以及用户是谁。其他服务也可以把这些令牌当作服务间调用的凭证来用；Kubernetes 和 AWS STS 已经在这么做了。
一个 ID Token——这是 dex 的核心功能。它是由 dex 签名的 JSON Web Token（JWT），带有标准声明（claims）：是哪个客户端应用为用户完成登录、令牌何时过期、以及用户是谁。其他服务也可以把这些令牌当作服务间调用的凭证来用；Kubernetes 和 AWS STS 已经在这么做了。每次登录都会让我的应用拿到刷新令牌（refresh token）吗？不会——上游协议的限制会传递下来。SAML 没有非交互式的方式来刷新断言（assertion），所以对于 SAML 登录，dex 不会签发刷新令牌；而 LDAP、GitHub、GitLab 和大多数其他连接器都可以。像 kubectl 这种需要离线访问（offline access）的场景，就得用支持刷新的连接器。
不会——上游协议的限制会传递下来。SAML 没有非交互式的方式来刷新断言（assertion），所以对于 SAML 登录，dex 不会签发刷新令牌；而 LDAP、GitHub、GitLab 和大多数其他连接器都可以。像 kubectl 这种需要离线访问（offline access）的场景，就得用支持刷新的连接器。那我为什么要在 LDAP 或 GitHub 前面加一层 dex？因为客户端只需针对 dex 编写一次认证逻辑，而由 dex 来实现各个后端的协议——要更换或新增提供商，只需修改 dex 的配置，而不用重写每一个应用。
因为客户端只需针对 dex 编写一次认证逻辑，而由 dex 来实现各个后端的协议——要更换或新增提供商，只需修改 dex 的配置，而不用重写每一个应用。它能对接 Azure AD 或 Salesforce 吗？可以，通过通用 OpenID Connect 连接器（beta），README 中说它覆盖 Salesforce 和 Azure 这类提供商；另有一个通用 OAuth 2.0 连接器，处于 alpha 阶段。
可以，通过通用 OpenID Connect 连接器（beta），README 中说它覆盖 Salesforce 和 Azure 这类提供商；另有一个通用 OAuth 2.0 连接器，处于 alpha 阶段。Which topics is it in?identity-management, saml, ldap, oidc, jwt, sso, oauth2, cloud-native, oauth, authentication, kubernetes, hacktoberfest
identity-management, saml, ldap, oidc, jwt, sso, oauth2, cloud-native, oauth, authentication, kubernetes, hacktoberfest