DC / OS - 身份验证与api令牌

时间：2016-09-17 11:20:43

标签： marathon dcos

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

我的问题是

  1. 我的假设是否正确？
  2. 身份验证令牌是否过期？如果是的话，什么时候有办法刷新它？

1 个答案:

答案 0 :(得分：12)

让我首先定义当前（1.8）Open 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令牌。

这大概是真的。但是，你称之为＆＃34;身份验证令牌＆＃34;实际上是OpenID Connect身份提供商发出的 OpenID Connect ID令牌。

让我们慢慢来看看这个，因为它有点牵扯。

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

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

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

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

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

（*）请注意，身份提供商仅在您成功向该提供商（例如Google帐户）验证后以及在您同意之后向您的浏览器发出ID令牌与第三方服务分享身份详细信息。

  

api token：通过使用请求正文中的身份验证令牌对RFC7517进行后调用来检索。此令牌用于授权针对api的调用。这样的令牌在5天后到期。

在DC / OS术语中，这是 DC / OS身份验证令牌。它是使用仅为DC / OS群集所知的随机密钥签名的JWT。 DC / OS中的管理路由器可以验证此类身份验证令牌。当针对管理路由器的某些HTTP请求仅代理到后端服务时，它们在请求中包含有效的身份验证令牌（因此，此令牌主要用于身份验证，但也是非常基本的粗粒度授权，如果你想这么说的话）。否则，管理员路由器将以401响应（读取：＆＃34;未经过身份验证＆＃34;）。

您的问题的答案

  

我的假设是否正确？

我希望澄清

  • 你所谓的＆＃34;身份验证令牌＆＃34;是一个OpenID Connect ID令牌（JWT）。
  • 你所说的＆＃34; api token＆＃34;被称为＆＃34; DC / OS身份验证令牌＆＃34;在DC / OS生态系统中（它在技术上也是JWT）。
  

身份验证令牌是否过期？

我将此问题读作＆＃34; OpenID Connect ID令牌是否会过期？＆＃34;确实是的！这是规范关于ID令牌到期的说法：

  

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

请注意，规范不强制执行特定的ID令牌生存期 - 这取决于身份提供商的设置。如果dcos.auth0.com发出了ID令牌，我刚刚确认了

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

也就是说，Auth0发出的ID令牌在5天后到期。

  

如果是的话，什么时候有办法刷新它？

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

请注意，Enterprise DC / OS提供了一个

的OpenID Connect身份验证流程
  • 在DC / OS和身份提供者之间安全地直接传递ID令牌（没有用户代理看到该ID令牌）。
  • 强制使用OpenID Connect ID令牌的可选nonce机制（描述为https://public-master-ip/acs/api/v1/auth/login），在多个级别引入更多概念安全性（例如减轻重放攻击）。

我们可能会通过下一个版本之一将该功能合并到Open DC / OS中（此时没有承诺！）。

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

相关问题
最新问题