marathon - DC/OS-身份验证与api token

Question

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


身份验证令牌：通过登录名检索
https://public-master-ip/login?redirect_uri=urn:ietf:wg:oauth:2.0:oob。该令牌用于检索api令牌。
api令牌：通过对https://public-master-ip/acs/api/v1/auth/login的后调用在请求正文中使用身份验证令牌来检索。该令牌用于授权针对api的调用。这样的令牌会在5天后过期。


我的问题是


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

Answer 1

让我首先定义当前（1.8）开放DC / OS身份验证过程的目标，然后逐步执行您的假设。之后，我会回答您的问题。

目标

当前开放式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显示一个内嵌框架，该内嵌框架加载由Auth0托管的一段JavaScript，当您在浏览器中执行该JavaScript时，它执行所谓的implicit flow（这是三个指定的OpenID Connect身份验证流程之一）类型）。

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

然后，接收ID令牌的JavaScript块-如您所说-将ID令牌POST到您的DC / OS集群（到https://public-master-ip/acs/api/v1/auth/login）。接收端是DC / OS的“管理路由器”（后者只是一个带皮筋的nginx）后面的Web应用程序。该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密钥集（JWKS）文档（通过RFC7517指定），揭示了与（假定）已对ID令牌签名的私钥相对应的公钥。因此，该Web应用程序将继续运行，并直接从身份提供者（通过HTTPS）获取公共密钥。然后，它使用该公共密钥来验证ID令牌的加密签名（当然，它也会检查到期时间）。如果通过了ID令牌验证，那么我所讨论的DC / OS Web应用程序正确地假设已根据Auth0对发送ID令牌的用户代理进行了成功验证。并且，信任Auth0，我们正确地假设用户代理已通过身份验证，例如Google帐户。

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

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


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


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

您的问题的答案


我的假设正确吗？


我希望已经澄清


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



身份验证令牌会过期吗？


我将这个问题读为“ OpenID Connect ID令牌会过期吗？”确实是的！这是规范关于ID令牌到期的说明：


exp-必填-到期时间，此后不得接受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 UI触发（唯一的）获取此类令牌并将其传递给DC / OS的预期方式，该UI为您启动了基于Auth0的流程（当然，您可以从技术上亲自将其破解）。 ..）。

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


直接在DC / OS和身份提供者之间安全地通信ID令牌（没有用户代理可以看到该ID令牌）。
强制使用OpenID Connect ID令牌的可选 nonce机制（描述为 in the spec），从而在多个级别上引入了更多概念上的安全性（例如减轻重播攻击）。


我们可能会在下一个发行版中将该功能合并到Open DC / OS中（目前没有保证！）。

希望对您有所帮助，让我知道是否还有其他问题。