DC/OS - 身份验证与 api 令牌
DC/OS - authentication vs. api token
据我所知，DC/OS 有两种不同类型的令牌：
身份验证令牌：通过登录检索
https://public-master-ip/login?redirect_uri=urn:ietf:wg:oauth:2.0:oob。此令牌用于检索 api 个令牌。
api 令牌：通过 post 调用 https://public-master-ip/acs/api/v1/auth/login 在请求正文中使用身份验证令牌检索.此令牌用于授权对 api 的调用。这样的令牌将在 5 天后过期。
我的问题是
- 我的假设是否正确？
- 身份验证令牌是否过期？如果是这样，什么时候可以刷新它？
让我先定义当前 (1.8) Open DC/OS 身份验证过程的目标，然后介绍您的假设。之后我会回答你的问题。
目标
当前 Open DC/OS 身份验证程序的目标是使用 Auth0 基础设施针对三个流行的身份提供者之一触发单点登录身份验证流程，并报告结果到 你的 DC/OS 集群。如果 DC/OS 集群对结果满意，它将发出专门针对该单个集群调整的身份验证令牌。
对您的假设的评论
authentication token: retrieved via a login through https://public-master-ip/login?redirect_uri=urn:ietf:wg:oauth:2.0:oob. This token is used to retrieve api tokens.
大致是这样。但是，您所说的“身份验证令牌”实际上是由 OpenID Connect 身份提供者发出的 OpenID Connect ID 令牌。
让我们慢慢来，因为它有点复杂。
幕后发生的是OpenID Connect单点登录身份验证流程。
更准确地说，DC/OS UI 显示一个 iframe，它加载了由 Auth0 托管的 JavaScript 的一部分，当在 your 浏览器——执行所谓的 implicit flow（这是三种指定的 OpenID Connect 身份验证流类型之一）。
在此流程结束时 (*)，在您的浏览器中执行的 JavaScript 代码会收到一个所谓的 OpenID Connect ID Token (from the identity provider, of course, which is Auth0 in this case). This token is a JSON Web Token (JWT, see RFC7519) 用身份的私钥签名提供商（在这种情况下，它实际上 是 Auth0，它基本上代理其他身份提供商，例如 Google 帐户）。
收到 ID 令牌的 JavaScript 片段——如您所说——将 ID 令牌发布到您的 DC/OS 集群（到 https:///public-master-ip/acs/api/v1/auth/login）。接收端是 DC/OS' Admin Router 后面的 Web 应用程序（后者只是一个拉皮条的 nginx）。该 Web 应用程序检查 ID 令牌的有效负载（即 JSON）并找到 key/value 对 "iss": "https://dcos.auth0.com/"。所以它知道谁（假装）发行了那个令牌！然后它继续获取 https://dcos.auth0.com/.well-known/openid-configuration (wooo, where does it know that URL from? This is magic defined by OpenID Connect Discovery 1.0 and RFC5785). That JSON document there defines a JSON Web Key Set (JWKS) document (specified via RFC7517)，显示 public 密钥对应于 private 密钥（据说) 签署了 ID 令牌。因此，该 Web 应用程序继续并从身份提供者（通过 HTTPS）直接 获取 public 密钥。然后它使用 public 密钥来验证 ID 令牌的加密签名（当然，它也会检查过期时间）。如果 ID 令牌验证通过，我提到的 DC/OS Web 应用程序会正确地假设发送 ID 令牌的用户代理已成功通过 Auth0 的身份验证。并且，信任 Auth0，我们理所当然地假设用户代理已经过身份验证，例如Google 个帐户。
然后它（我谈到的 DC/OS 中的小型 Web 应用程序）将身份存储在 DC/OS 中，分配一个唯一的用户 ID，并发出 DC/OS 身份验证令牌。该令牌通过指定的用户 ID 引用给定的身份。
(*)请注意，身份提供者 仅 在您成功向该提供者验证自己后向您的浏览器发出 ID 令牌（例如 Google 帐户）并在您同意与第三方服务共享身份详细信息后。
api token: retrieved via a post call to https://public-master-ip/acs/api/v1/auth/login with the authentication token in the request body. This token is used to authorize calls against the apis. Such a token expires after 5 days.
在 DC/OS 术语中，这是 DC/OS 身份验证令牌。它是一个 JWT，使用只有您的 DC/OS 集群知道的随机密钥签名。 DC/OS 中的 Admin Router 可以验证此类身份验证令牌。某些针对 Admin Router 的 HTTP 请求 仅 代理到后端服务，当它们在请求中包含有效的身份验证令牌时（因此，此令牌主要服务于 身份验证，但也是一个非常基本的粗粒度 授权，如果你想这么说的话）。否则，Admin Router 将以 401 响应（读作：“未通过身份验证”）。
您问题的答案
Are my assumptions correct?
我希望已经澄清了
- 您所说的“身份验证令牌”是一个 OpenID Connect ID 令牌（JWT）。
- 你所说的“api 令牌”就是 DC/OS 生态系统中所谓的“DC/OS 身份验证令牌”（从技术上讲，它也是一个 JWT）。
Does a authentication token expire?
我将这个问题解读为“OpenID Connect ID 令牌是否过期？”确实是的！这是规范中关于 ID 令牌过期的内容：
exp -- REQUIRED -- Expiration time on or after which the ID Token MUST NOT be accepted for processing. The processing of this parameter requires that the current date/time MUST be before the expiration date/time listed in the value. Implementers MAY provide for some small leeway, usually no more than a few minutes, to account for clock skew. Its value is a JSON number representing the number of seconds from 1970-01-01T0:0:0Z as measured in UTC until the date/time. See RFC 3339 [RFC3339] for details regarding date/times in general and UTC in particular.
请注意，该规范 不会 强制执行特定的 ID 令牌生命周期——这取决于身份提供者来设置。如果是 dcos 发出的 ID 令牌。auth0.com 我刚刚确认
>>> exp = 1474742063
>>> iat = 1474310063
>>> lifetime_days = (exp - iat) / (60.0 * 60 * 24)
>>> lifetime_days
5.0
也就是说，Auth0 发出的 ID Token 在 5 天后过期。
If so, when and is there a way to refresh it?
您只能通过涉及配置的身份提供者之一的 OpenID Connect 身份验证流程来获取 Auth0 发出的新 ID 令牌。也就是说，获取此类令牌并将其传递给 DC/OS 的（唯一）预期方式是通过 DC/OS UI 触发的，它会为您启动基于 Auth0 的流程（好吧，从技术上讲，您可以自己将其组合在一起...)。
请注意，企业 DC/OS 提供了一个 OpenID Connect 身份验证流程，
- 直接在 DC/OS 和身份提供者之间安全地传递 ID 令牌（没有用户代理会看到该 ID 令牌）。
- 强制使用 OpenID Connect ID 令牌的可选
nonce 机制（描述 in the spec），在多个层面引入更多概念性安全（例如减轻重放攻击）。
我们可能会在下一个版本中将该功能合并到 Open DC/OS 中（目前没有承诺！）。
希望对您有所帮助，如果还有其他问题，请告诉我。
据我所知，DC/OS 有两种不同类型的令牌：
身份验证令牌：通过登录检索 https://public-master-ip/login?redirect_uri=urn:ietf:wg:oauth:2.0:oob。此令牌用于检索 api 个令牌。
api 令牌：通过 post 调用 https://public-master-ip/acs/api/v1/auth/login 在请求正文中使用身份验证令牌检索.此令牌用于授权对 api 的调用。这样的令牌将在 5 天后过期。
我的问题是
- 我的假设是否正确？
- 身份验证令牌是否过期？如果是这样，什么时候可以刷新它？
让我先定义当前 (1.8) Open DC/OS 身份验证过程的目标，然后介绍您的假设。之后我会回答你的问题。
目标
当前 Open DC/OS 身份验证程序的目标是使用 Auth0 基础设施针对三个流行的身份提供者之一触发单点登录身份验证流程，并报告结果到 你的 DC/OS 集群。如果 DC/OS 集群对结果满意，它将发出专门针对该单个集群调整的身份验证令牌。
对您的假设的评论
authentication token: retrieved via a login through https://public-master-ip/login?redirect_uri=urn:ietf:wg:oauth:2.0:oob. This token is used to retrieve api tokens.
大致是这样。但是，您所说的“身份验证令牌”实际上是由 OpenID Connect 身份提供者发出的 OpenID Connect ID 令牌。
让我们慢慢来，因为它有点复杂。
幕后发生的是OpenID Connect单点登录身份验证流程。
更准确地说，DC/OS UI 显示一个 iframe，它加载了由 Auth0 托管的 JavaScript 的一部分，当在 your 浏览器——执行所谓的 implicit flow（这是三种指定的 OpenID Connect 身份验证流类型之一）。
在此流程结束时 (*)，在您的浏览器中执行的 JavaScript 代码会收到一个所谓的 OpenID Connect ID Token (from the identity provider, of course, which is Auth0 in this case). This token is a JSON Web Token (JWT, see RFC7519) 用身份的私钥签名提供商（在这种情况下，它实际上 是 Auth0，它基本上代理其他身份提供商，例如 Google 帐户）。
收到 ID 令牌的 JavaScript 片段——如您所说——将 ID 令牌发布到您的 DC/OS 集群（到 https:///public-master-ip/acs/api/v1/auth/login）。接收端是 DC/OS' Admin Router 后面的 Web 应用程序（后者只是一个拉皮条的 nginx）。该 Web 应用程序检查 ID 令牌的有效负载（即 JSON）并找到 key/value 对 "iss": "https://dcos.auth0.com/"。所以它知道谁（假装）发行了那个令牌！然后它继续获取 https://dcos.auth0.com/.well-known/openid-configuration (wooo, where does it know that URL from? This is magic defined by OpenID Connect Discovery 1.0 and RFC5785). That JSON document there defines a JSON Web Key Set (JWKS) document (specified via RFC7517)，显示 public 密钥对应于 private 密钥（据说) 签署了 ID 令牌。因此，该 Web 应用程序继续并从身份提供者（通过 HTTPS）直接 获取 public 密钥。然后它使用 public 密钥来验证 ID 令牌的加密签名（当然，它也会检查过期时间）。如果 ID 令牌验证通过，我提到的 DC/OS Web 应用程序会正确地假设发送 ID 令牌的用户代理已成功通过 Auth0 的身份验证。并且，信任 Auth0，我们理所当然地假设用户代理已经过身份验证，例如Google 个帐户。
然后它（我谈到的 DC/OS 中的小型 Web 应用程序）将身份存储在 DC/OS 中，分配一个唯一的用户 ID，并发出 DC/OS 身份验证令牌。该令牌通过指定的用户 ID 引用给定的身份。
(*)请注意，身份提供者 仅 在您成功向该提供者验证自己后向您的浏览器发出 ID 令牌（例如 Google 帐户）并在您同意与第三方服务共享身份详细信息后。
api token: retrieved via a post call to https://public-master-ip/acs/api/v1/auth/login with the authentication token in the request body. This token is used to authorize calls against the apis. Such a token expires after 5 days.
在 DC/OS 术语中，这是 DC/OS 身份验证令牌。它是一个 JWT，使用只有您的 DC/OS 集群知道的随机密钥签名。 DC/OS 中的 Admin Router 可以验证此类身份验证令牌。某些针对 Admin Router 的 HTTP 请求 仅 代理到后端服务，当它们在请求中包含有效的身份验证令牌时（因此，此令牌主要服务于 身份验证，但也是一个非常基本的粗粒度 授权，如果你想这么说的话）。否则，Admin Router 将以 401 响应（读作：“未通过身份验证”）。
您问题的答案
Are my assumptions correct?
我希望已经澄清了
- 您所说的“身份验证令牌”是一个 OpenID Connect ID 令牌（JWT）。
- 你所说的“api 令牌”就是 DC/OS 生态系统中所谓的“DC/OS 身份验证令牌”（从技术上讲，它也是一个 JWT）。
Does a authentication token expire?
我将这个问题解读为“OpenID Connect ID 令牌是否过期？”确实是的！这是规范中关于 ID 令牌过期的内容：
exp -- REQUIRED -- Expiration time on or after which the ID Token MUST NOT be accepted for processing. The processing of this parameter requires that the current date/time MUST be before the expiration date/time listed in the value. Implementers MAY provide for some small leeway, usually no more than a few minutes, to account for clock skew. Its value is a JSON number representing the number of seconds from 1970-01-01T0:0:0Z as measured in UTC until the date/time. See RFC 3339 [RFC3339] for details regarding date/times in general and UTC in particular.
请注意，该规范 不会 强制执行特定的 ID 令牌生命周期——这取决于身份提供者来设置。如果是 dcos 发出的 ID 令牌。auth0.com 我刚刚确认
>>> exp = 1474742063
>>> iat = 1474310063
>>> lifetime_days = (exp - iat) / (60.0 * 60 * 24)
>>> lifetime_days
5.0
也就是说，Auth0 发出的 ID Token 在 5 天后过期。
If so, when and is there a way to refresh it?
您只能通过涉及配置的身份提供者之一的 OpenID Connect 身份验证流程来获取 Auth0 发出的新 ID 令牌。也就是说，获取此类令牌并将其传递给 DC/OS 的（唯一）预期方式是通过 DC/OS UI 触发的，它会为您启动基于 Auth0 的流程（好吧，从技术上讲，您可以自己将其组合在一起...)。
请注意，企业 DC/OS 提供了一个 OpenID Connect 身份验证流程，
- 直接在 DC/OS 和身份提供者之间安全地传递 ID 令牌（没有用户代理会看到该 ID 令牌）。
- 强制使用 OpenID Connect ID 令牌的可选
nonce机制（描述 in the spec），在多个层面引入更多概念性安全（例如减轻重放攻击）。
我们可能会在下一个版本中将该功能合并到 Open DC/OS 中（目前没有承诺！）。
希望对您有所帮助，如果还有其他问题，请告诉我。