取消刷新标记

我已在Vittorio的博客上发布此评论两次，这里是http://blogs.msdn.com/b/vbertocci/archive/2015/08/13/adal-3-didnt-return-refresh-tokens-for-5-months-and-nobody-noticed.aspx，但它在评论中从未出现，所以我将它添加到此处。取消刷新标记

我们有一个特定的场景，我们使用RT，它是在Windows服务的上下文中没有交互式用户，会话信息可以意外启动和停止，并且开发可分发自定义ADAL缓存机制。 RT是合乎逻辑的选择，这似乎是您在此处其他评论中描述的场景类型。今天，ADAL没有解决这个问题，RT确实如此，我还没有看到任何删除它们的商业理由 - 只是为了保留它们。去除RT将对使用此解决方案的大约100多位客户产生不利影响。如果你在ADAL中有另一个可行的解决方案，我们很乐意使用它，但是如果没有，那么为某种协议纯粹理由移除RT将是一个大问题。

来源

2015-08-24 Steve Peschka

您使用的博客只是一个转发器，因为最近2年的职位应该清楚。实际的帖子在www.cloudidentity.com上。对于任何“协议纯化原因”，RT都没有被删除，特别是因为绝对没有任何从协议的角度进行更改 - 这只是库是否透明地使用RT，或者代码确实如此。您链接的帖子提供了导致该决定的具体可用性和功能原因。我不明白你所关心的问题。无论您今天使用什么机制来共享和/或保留RT，您都可以使用它来完成与缓存完全相同的操作 - 它可以像每个服务的平面文件一样简单，不需要做任何分发的事情，如果这使得您紧张。此外，您描述的拓扑并不严格依赖刷新令牌 - 如果您将客户端建模为机密客户端，则意味着您随时可以交换访问令牌的凭据，而刷新令牌的意思是机制不会一直提示用户，同时保留撤销它们的能力。客户端凭据将遵循完全不同的撤销路径，因此人们不得不想知道为什么您首先会担心刷新令牌。最后：这个变化发生在ADAL v3中。没有什么能阻止你继续使用ADAL v2，这就是为什么我们在介绍重大更改时使用主要版本。

来源

2015-08-24 16:43:52 vibronet

我很高兴在线下讨论具体细节（因为我在博客文章中提出了我的原创意见），但是在多客户分布式环境中存在安全隐患，将应用程序建模为无效一个机密的客户。 ADAL团队似乎没有认真对待这类情景。其结果是我们必须尽我们所能解决这些限制，例如使用RT和其他方法。博客文章中描述的基本原理缺少任何商业相关的动机，这就是为什么它缺乏合理性。 –

如果您想提及您感兴趣的场景，而不分享任何敏感细节，那将有所帮助。 ADAL主要是Azure AD服务提供的投影，如果AAD不支持这些服务，则缺少对库中某些场景的支持。我不确定你的意思是什么“与商业有关的动机”。 RT的出现促使一些开发人员在他们的代码中做了一些危险的事情：如果没有这是Azure AD支持的方案的阻碍因素，那么删除是有意义的。它已经促使许多人发现并消除他们应用中的问题。 – vibronet

在评论部分所允许的600多个字符中，我所能达到的不仅仅是这些，但如果您通过[email protected]向我发送电子邮件，我将描述我们难以用ADAL管理的两个特定挑战。 –

取消刷新标记

回答

相关问题