- SAML Applications
- SCIM
- API Tokens
-
API service integrations access (OAuth 2.0)
There are certain aspects of an Okta organization that are tied to the creator, such as API tokens and OIDC Refresh tokens. API tokens have the same permissions as the admin who created them, and their status is tied to the status of the admin who created them. This means that if the admin is deactivated or their permissions are modified, the API tokens that they created will also be affected.
OIDC Refresh tokens are another example of a feature that is tied to the creator. These tokens are used to manage app provisioning on both the Okta and application side. If the admin who created the OIDC Refresh token is deactivated or their permissions are modified, it can affect the provisioning feature of the associated application.
Therefore, it is important to consider the long-term impact of creating these types of features and to ensure that they are created using service accounts or other accounts that are not tied to a specific admin to avoid any disruption in functionality in case of admin deactivation or permission changes.
It is recommended to use service accounts for applications that require continuous functionality and do not rely on specific users or administrators. These service accounts should not be tied to any individual and should be accessible by multiple members of the administration team if necessary.
In situations where integration is linked to a particular admin and that admin has left the organization, resulting in the deactivation of the associated Okta account, it is necessary to modify the applications that the admin account is associated with. This will ensure that they can continue to use the necessary rights and features of another admin or a service account, preferably.
Alternatively, the admin account that needs to be deactivated can be converted into a service account, and the user's credentials can be reset while changing specific attributes, such as the email address, to prevent account recovery.
