SSO＆amp;现有的OAuth集成

Question

晚安，

我的小组正在推出SSO - yay。我们有几个应用程序直接使用Box.com进行身份验证，并且所有令牌刷新都会自动处理。迁移到SSO后，我们在AD中未包含这些服务（app）帐户，因此他们无法通过SSO网关进行访问。

我（可能不正确）了解OAuth与循环中SSO提供程序的工作原理：

我们仍然可以直接使用框启动OAuth握手 - 但是框会将此请求转发给SSO提供商。然后，SSO提供商将对凭据进行身份验证并传回＆＃34;所有好的＆＃34;到框，将发出auth_token。

这是基于以下方框：

  

＆＃34;如果您通过Box的OAuth 2.0验证您的应用程序，您的   应用程序将自动让客户与他们签约   公司凭证，就像他们对其他所有Box一样   应用。这也适用于流行的商业服务   Okta，One Login和Ping。＆＃34;

https://docs.box.com/docs/oauth-20

以及这张照片：

所以如果外部应用程序＆＃39;在SSO的AD中没有Box的服务帐户（太多首字母缩略词），它们不应该能够正确验证吗？

但是这些应用程序仍在继续进行身份验证。即使在迁移到SSO之后，他们也能够刷新令牌并继续访问盒子。

我理解的缺陷在哪里？这些应用程序是否需要添加到AD中，或者这种SSO的推出不会影响我们的任何外部依赖项吗？

谢谢！

Answer 1

从框中得到答案：

  

第三方应用和集成使用持久身份验证   令牌模型。这意味着除非用户故意将其注销   应用程序，或管理员停用或删除他们的帐户，这   初次登录后，用户永远不必重新进行身份验证。代替，   应用程序/集成将刷新其令牌。令人耳目一新的令牌   生成时不需要单步执行SSO登录流程   初始令牌集。

     

SSO状态的更改，无论是在SSO关闭，启用还是必需之间，   或者在两个不同的连接之间，对现有连接没有影响   认证会话。用户在SSO时不会被强行注销   打开了。

     

下次登录尝试时，新的SSO流程将起作用。在这种情况下，这些用户已经过身份验证   在SSO推出之前。 SSO的变化会影响到的行为   这些用户需要通过SSO进行身份验证;   但是，由于持久的身份验证模型，下一次登录＆＃34;   实际上从未发生过，这些用户可以继续刷新令牌   并保持访问权限，而不会受到进行身份验证的挑战   IdP再次。