5

据我所知，DC/OS 有两种不同类型的令牌：

我的问题是

  1. 我的假设正确吗？
  2. 身份验证令牌是否过期？如果是这样，何时以及有没有办法刷新它？
4

1 回答 1

12

让我首先定义当前 (1.8) 开放 DC/OS 身份验证过程的目标，然后介绍您的假设。之后我会回答你的问题。

目标

当前 Open DC/OS 身份验证过程的目标是使用Auth0基础架构针对三个流行的身份提供者之一触发单点登录身份验证流程，并将结果报告回您的DC/OS 集群。如果 DC/OS 集群对结果满意，它将发出专门针对该单独集群调整的身份验证令牌。

评论你的假设

身份验证令牌：通过 https://public-master-ip/login?redirect_uri=urn:ietf:wg:oauth:2.0:oob 登录检索。此令牌用于检索 api 令牌。

这大致是真的。但是，您所说的“身份验证令牌”实际上是由 OpenID Connect 身份提供者发出的OpenID Connect ID 令牌。

让我们慢慢来，因为它有点涉及。

幕后发生的是OpenID Connect单点登录身份验证流程。

更准确地说，DC/OS UI 显示一个 iframe，它加载由 Auth0 托管的一段 JavaScript，当在您的浏览器中执行时，它执行所谓的隐式流（这是三种指定的 OpenID Connect 身份验证流类型之一）。

在这个 flow( *) 结束时，在您的浏览器中执行的 JavaScript 代码会收到一个所谓的 OpenID Connect ID 令牌（当然，来自身份提供者，在本例中是 Auth0）。此令牌是一个 JSON Web 令牌（JWT，参见RFC7519），使用身份提供者的私钥签名（在这种情况下，它实际上是Auth0，它基本上代理其他身份提供者，例如 Google 帐户）。

然后接收 ID 令牌的 JavaScript 片段——正如你所说——将 ID 令牌发布到您的 DC/OS 集群（到 https://public-master-ip/acs/api/v1/auth/login）。接收端是 DC/OS 的 Admin Router 后面的 Web 应用程序（后者只是一个 pimped nginx）。该 Web 应用程序检查 ID 令牌的有效负载（即 JSON）并找到键/值对"iss": "https://dcos.auth0.com/"。所以它知道谁（假装）发行了那个令牌！然后它继续并获取https://dcos.auth0.com/.well-known/openid-configuration（哇，它从哪里知道那个 URL？这是OpenID Connect Discovery 1.0和RFC5785定义的魔法）。那里的 JSON 文档定义了一个 JSON Web Key Set (JWKS) 文档（通过RFC7517指定），揭示了对应于已（假定）签署 ID 令牌的私钥的公钥。因此，该 Web 应用程序继续并直接从身份提供者（通过 HTTPS）获取公钥。然后，它使用该公钥来验证 ID 令牌的加密签名（当然，它也会检查过期时间）。如果 ID 令牌验证通过，我谈到的 DC/OS Web 应用程序正确地假定发送 ID 令牌的用户代理已成功通过 Auth0 身份验证。而且，信任 Auth0，我们正确地假设用户代理是针对例如 Google 帐户进行身份验证的。

只有这样它（我谈到的 DC/OS 中的小型 Web 应用程序）才会在 DC/OS 中存储身份，分配唯一的用户 ID，并发出DC/OS 身份验证令牌。该令牌通过指定的用户 ID 引用给定的身份。

( *)请注意，只有在您向该提供商（例如 Google 帐户）成功验证自己并同意与第三方服务共享身份详细信息后，身份提供商才会向您的浏览器发出 ID 令牌。

api 令牌：通过使用请求正文中的身份验证令牌对 https://public-master-ip/acs/api/v1/auth/login 的 post 调用检索。此令牌用于授权对 api 的调用。这样的令牌将在 5 天后过期。

在 DC/OS 术语中，这是DC/OS 身份验证令牌。它是使用只有 DC/OS 集群知道的随机密钥签名的 JWT。DC/OS 中的 Admin Router 可以验证此类身份验证令牌。某些针对 Admin Router 的 HTTP 请求仅在请求中包含有效的身份验证令牌时才被代理到后端服务（因此，此令牌主要用于身份验证，但也是一个非常基本的粗粒度授权，如果你想说的话） . 否则，Admin Router 将以 401 响应（阅读：“未通过身份验证”）。

回答您的问题

我的假设正确吗？

我希望已经澄清

  • 您所说的“身份验证令牌”是 OpenID Connect ID 令牌（JWT）。
  • 你所说的“api 令牌”就是 DC/OS 生态系统中所谓的“DC/OS 身份验证令牌”（从技术上讲，它也是 JWT）。

身份验证令牌是否过期？

我将此问题读作“OpenID Connect ID 令牌是否过期？” 确实是的！这是规范所说的关于 ID 令牌过期的内容：

exp -- 必需 -- ID 令牌不能被接受处理的过期时间或之后。此参数的处理要求当前日期/时间必须在值中列出的到期日期/时间之前。实施者可以提供一些小的余地，通常不超过几分钟，以解决时钟偏差。它的值是一个 JSON 数字，表示从 1970-01-01T0:0:0Z 到日期/时间的秒数，以 UTC 度量。请参阅 RFC 3339 [RFC3339] 了解有关一般日期/时间和特别是 UTC 的详细信息。

请注意，该规范不强制执行特定的 ID 令牌生命周期——这取决于身份提供者来设置。如果是 dcos.auth0.com 发出的 ID 令牌，我刚刚确认

>>> exp = 1474742063
>>> iat = 1474310063
>>> lifetime_days = (exp - iat) / (60.0 * 60 * 24)
>>> lifetime_days
5.0

即 Auth0 发出的 ID Token 在 5 天后过期。

如果是这样，何时以及有没有办法刷新它？

您只能通过涉及已配置身份提供者之一的 OpenID Connect 身份验证流程来获取 Auth0 发出的新 ID 令牌。也就是说，获取此类令牌并将其传递给 DC/OS 的（唯一）预期方式是通过 DC/OS UI 触发的，该 UI 将为您启动基于 Auth0 的流程（好吧，您可以在技术上自己破解它。 ..)。

请注意，Enterprise DC/OS 提供了一个 OpenID Connect 身份验证流程，该流程

  • 直接在 DC/OS 和身份提供者之间安全地通信 ID 令牌（没有用户代理看到该 ID 令牌）。
  • 强制使用nonceOpenID Connect ID 令牌的可选机制（在规范中描述），在多个级别引入更多概念安全性（例如减轻重放攻击）。

我们可能会在下一个版本中将该功能合并到 Open DC/OS 中（目前还没有承诺！）。

希望对您有所帮助，如果还有其他问题，请告诉我。

于 2016-09-19T18:59:18.950 回答