据我所知,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天后到期.
我的问题是
Jan*_*cke 12
让我首先定义当前(1.8)Open DC/OS身份验证过程的目标,然后逐步完成您的假设.之后我会回答你的问题.
目前开放式DC/OS认证过程的目的是使用Auth0基础设施触发对三只俗身份提供一个单点登录认证流程,并有报告给结果的 DC/OS集群.如果DC/OS群集对结果满意,它将发出专门调整到该单个群集的身份验证令牌.
认证令牌:经由通过登录检索的https://公共主-IP /登录REDIRECT_URI =瓮: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'管理路由器后面的Web应用程序(后者只是一个拉皮条的nginx).该Web应用程序检查ID令牌的有效负载(即JSON)并找到键/值对"iss": "https://dcos.auth0.com/".所以它知道谁(假装)发出了这个令牌!然后它继续并获取https://dcos.auth0.com/.well-known/openid-configuration(wooo,它在哪里知道来自哪个URL？这是由OpenID Connect Discovery 1.0和RFC5785定义的魔法).这JSON文件有定义了一个JSON网络密钥集(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的后置调用来检索.此令牌用于授权针对api的调用.这样的令牌在5天后到期.
在DC/OS术语中,这是DC/OS身份验证令牌.它是使用仅为DC/OS群集所知的随机密钥签名的JWT.DC/OS中的管理路由器可以验证此类身份验证令牌.针对管理路由器的某些HTTP请求仅在请求中包含有效身份验证令牌时才会代理到后端服务(因此,此令牌主要用于身份验证,但如果您想这样做,则还需要非常基本的粗粒度授权) .否则,管理员路由器将以401响应(读取:"未经过身份验证").
我的假设是否正确？
我希望澄清一下
身份验证令牌是否过期？
我把这个问题读作"OpenID Connect ID Token到期了吗？" 确实是的!这是规范关于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身份验证流程
nonceOpenID Connect ID Tokens 的可选机制(在规范中描述),在多个级别引入更多概念安全性(例如减轻重放攻击).我们可能会通过下一个版本之一将该功能合并到Open DC/OS中(此时没有承诺!).
我希望有所帮助,如果还有其他问题,请告诉我.