Re-authorization always succeeds for users suspended in Identity Provider

We are using Okta developer account that is connected to other identity providers like PingOne and Okta itself (via Okta-to-Okta connection). After initial authentication, if a user account is suspended in the Identity Provider, it still successfully authenticates from the native app on re-authorizations that do not prompt the user for username/passwd. Looks like Okta developer service is blindly issuing a new token or refreshing the token using refresh token (we have tried both methods) without checking the state of the user with the Identity Provider.
We just want to make sure that the user doesn’t need to enter username/password every hour to keep using the app, but when the user account with the identity provider is suspended or deactivated, the token refresh should fail. Does that work? Is there a recommended way of achieving the same even while using Okta-to-Okta connection from developer to IdP?

Hi @bayunsystems

Did you set up a profile mastering with Okta and PingOne in the Okta service provider tenant? Through profile mastering, the user can be suspended depending on it’s status in the identity provider. Based on the scenario that you’ve provided, the Single Sign On option will not have any effect over the suspension / deprovisioning.

Hi @dragos. When I look at the profile of the user in Okta-developer portal, that has been automatically created based on the details it got from Okta-enterprise at the time of first sign-in (via the Okta-to-Okta connection), it already says “Profile mastered by OIDC IdP” right at the top. Also, it says “You can’t edit this user’s profile because their account is mastered by OIDC IdP”. So I assume it is already setup correctly by default when I had configured the Okta-to-Okta connection from Okta-developer to Okta-enterprise. Is there anything else I need to do? I saw explicit instructions for other apps and directories here:

However, I didn’t see any instructions for specifically enabling this for an OIDC connection to an IdP.

I hope you understand my scenario correctly. Why do you say that based on my scenario, the SSO option will not have any effect over the suspension/deprovisioning. All I want to do is make sure that when a user’s profile is mastered by an IdP (Okta-enterprise in this case), the Okta-developer somehow suspends the user in its own internal database when that user is suspended in the IdP, or shortly there-after. In the behavior I am seeing, Okta-developer continues to successfully authenticate the user without any problem as long as the browser session from the user-device to Okta-developer is still active. And this browser-session is very long-lived (multiple days?). So even after a user account has been suspended in Okta-enterprise, which is the profile master in this case, Okta-developer keeps refreshing the token from a mobile app on every subsequent request without even checking the status with Okta-enterprise for a long time (multiple days at least) after the first authentication and session-establishment. This doesn’t seem to make sense. There has to be some recommended way to solve this problem.

Hi @bayunsystems

When using the OpenID IdP, the access token created by the identity provider is parsed by Okta and, depending on the configuration, it can create the user and/or update the user’s Okta profile.

In the case of deprovisioning, this feature does not have any way of contacting the identity provider and receive the status of the user in order to mirror it in Okta.

Hi @dragos

Thanks for the update. All we want to achieve is the following:

  1. While the user account is active with the IdP, user should be able to continue using the mobile-app without having to enter credentials again and again after first successful login.
  2. On account suspension/deprovisioning with the IdP, the user should be forced to enter credentials again after at most a few minutes of use (maybe an hour or so). So the user should not be able to continue using the app for more than an hour after account suspension.

Is there a recommended way to achieve this? I think this should be a very common need out there. Or rather need for every enterprise developer using a mobile-app to authenticate against Okta’s developer product. So there has to be some way of solving this problem. Can you please check with your internal engineering or product management team to find out what the recommended solution is.

Thanks in advance for your help.

Hi @bayunsystems

You can check out the Org2Org application here to achieve the provisioning/deprovisioning part.