SSO和现有的OAuth集成
晚上好，
我的团队正在推出SSO - 耶。 我们有几个直接使用Box.com进行身份验证的应用程序，所有的令牌刷新都会自动处理。 在我们迁移到SSO后，我们没有在我们的AD中包含这些服务（应用）帐户，因此他们无法通过SSO网关进行访问。
我（可能不正确）了解循环中的SSO提供者的OAuth如何工作：
我们仍然可以直接使用框启动OAuth握手 - 但Box会将此请求转发给SSO提供商。 然后，SSO提供程序将验证凭据并将“所有好”传回给框，这会发出auth_token。
这是基于以下方框：
“如果您通过Box的OAuth 2.0验证您的应用程序，您的应用程序将自动让客户使用其公司证书登录，就像他们对其他Box应用程序一样，这也适用于流行的商业服务，如Okta，One Login和平安“。
https://docs.box.com/docs/oauth-20
以及这张照片： 
因此，如果带有Box的外部应用程序的服务帐户不在SSO的AD中（太多首字母缩略词），它们就不应该能够正确认证？
但是这些应用程序仍然可以进行身份验证。 即使在迁移到SSO后，他们也能够刷新令牌并继续访问邮箱。
我的理解缺陷在哪里？ 这些应用程序是否需要添加到AD中，还是不会影响我们的任何外部依赖关系？
谢谢！
从框中获得答案：
第三方应用程序和集成使用持久性身份验证令牌模型。 这意味着，除非用户故意将其注销到应用程序外，否则管理员将取消激活或删除其帐户，否则此用户将无需在首次登录后重新进行身份验证。 相反，应用程序/集成将刷新其令牌。 刷新令牌不需要逐步通过SSO登录流程，而生成初始令牌集合。
SSO状态的更改（无论SSO关闭，已启用和必需，还是两个不同连接之间）都不会影响现有的身份验证会话。 启用SSO时，用户不会被强制注销。
在下次登录尝试时，新的SSO流程将发挥作用。 在这种情况下，这些用户在SSO推出之前已经通过身份验证。 SSO更改会影响行为，因为这些用户需要通过SSO进行身份验证; 但是，由于采用持久性身份验证模式，“下一次登录”实际上从未发生过，并且这些用户可以继续刷新令牌并保留访问权限，而不会再被质疑再次向IdP进行身份验证。
链接地址: http://www.djcxy.com/p/47973.html