SSO & Existing OAuth integrations
Good Evening,
My group is rolling out SSO - yay. We have several applications that directly authenticate with Box.com and all token refreshes are handled automatically. After we migrated to SSO, we didn't include these service (app) accounts in our AD, so they do not have access via the SSO gateway.
My (likely incorrect) understanding of how OAuth with an SSO provider in the loop works:
We can still start the OAuth handshake directly with box - but box will forward this request to the SSO provider. The SSO provider will then authenticate the credentials and pass back a "all good" to box, which will issue an auth_token.
This is based off of the following from box:
"If you authenticate your application via Box's OAuth 2.0, your application will automatically let the customer sign-on with their company credentials, just like they do with every other Box application. This also applies to popular commercial services like Okta, One Login, and Ping."
https://docs.box.com/docs/oauth-20
As well as this photo: 
So if the external applications' service accounts with Box aren't in the AD of the SSO (too many acronyms), they should not be able to authenticate right?
But these apps are continuing to be able to authenticate. They are able to refresh their token and continue accessing box, even after the migration to SSO.
Where is the flaw in my understanding? Will these apps need to be added to the AD, or does this roll out of SSO not affect any of our external dependencies?
Thanks!
Got an answer from box:
third-party apps and integrations use a persistent authentication token model. This means that unless a user deliberately logs them out of the app, or an admin inactivates or deletes their account, this user will never have to re-authenticate after initial login. Instead, the app/integration will refresh their tokens. Refreshing tokens does not require stepping through the SSO login flow, while generating an initial set of tokens does.
Changes in SSO status, whether between SSO Off, Enabled, and Required, or between two different connections, have no effect on existing authentication sessions. Users won't be forcibly logged out when SSO is turned on.
Upon next login attempt will the new SSO flow come into play. In this case, these users were already authenticated into the integration prior to SSO roll-out. The SSO change would have impacted behavior in that these users would need to authenticate via SSO going forward; however, due to the persistent authentication model, that "next login" never actually happens, and these users can continue to refresh tokens and retain access without ever being challenged to authenticate into the IdP again.
链接地址: http://www.djcxy.com/p/47974.html下一篇: SSO和现有的OAuth集成