Okta App Registration

Create an API service application in Okta to authenticate the OpenHound Okta collector.

The OpenHound Okta collector authenticates to the Okta API using an OAuth 2.0 service application with a public/private key pair.

To create the Okta application registration for the OpenHound Okta collector, follow the steps below.

1. Open the Applications page

   In the Okta Admin Console, navigate to Applications > Applications and click Create App Integration.

   
2. Select API Services

   In the Create a new app integration dialog, select API Services and click Next.

   
3. Name the application

   Enter a name for the app integration and click Save.

   
4. Configure public key authentication

   After the application is created, you are taken to the General tab. Make a note of the newly created application’s Client ID for the collector.

   

   Under Client Credentials, click Edit and change Client authentication from Client secret to Public key / Private key.

   
5. Generate a key pair

   Under PUBLIC KEYS, click Add key, then click Generate new key.

   

   

   Copy the private key (JSON) and store it securely — it is only displayed once.

   Click Done to close the key dialog.

6. Save the credentials

   Verify the key appears in the PUBLIC KEYS table, then click Save.

   

   Confirm the prompt that existing client secrets will no longer be used.

   
7. Disable DPoP requirement

   Uncheck the Require Demonstrating of Proof of Possession (DPoP) option and click Save.

   
8. Grant OAuth 2.0 scopes

   Navigate to the Okta API Scopes tab and grant the scopes required by the OpenHound Okta collector.

   The Okta application registration used by the OpenHound Okta collector requires the following OAuth 2.0 scopes for data collection to function correctly:

   OAuth 2.0 Scope	Description
   okta.agentPools.read	Allows the app to read agent pools in your Okta organization.
   okta.apiTokens.read	Allows the app to read API tokens in your Okta organization.
   okta.appGrants.read	Allows the app to read grants in your Okta organization.
   okta.apps.read	Allows the app to read information about Apps in your Okta organization.
   okta.authenticators.read	Allows the app to read authenticators in your Okta organization.
   okta.authorizationServers.read	Allows the app to read information about authorization servers in your Okta organization.
   okta.clients.read	Allows the app to read OAuth 2.0 clients in your Okta organization.
   okta.devices.read	Allows the app to read the existing device’s profile and search devices.
   okta.features.read	Allows the app to read information about features in your Okta organization.
   okta.groups.read	Allows the app to read information about groups and their members in your Okta organization.
   okta.idps.read	Allows the app to read information about identity providers in your Okta organization.
   okta.oauthIntegrations.read	Allows the app to read API service integration instances in your Okta organization.
   okta.orgs.read	Allows the app to read organization-specific details about your Okta organization.
   okta.policies.read	Allows the app to read information about policies in your Okta organization.
   okta.realmAssignments.read	Allows the app to read realm assignments in your Okta organization.
   okta.realms.read	Allows the app to read the existing realms and their details.
   okta.roles.read	Allows the app to read administrative role assignments for users in your Okta organization.
   okta.users.read	Allows the app to read the existing users’ profiles and credentials.

   The okta.realms.read and okta.realmAssignments.read scopes are optional and requires Okta Identity Governance or Secure Partner Access.

9. Assign admin roles

   In addition to the OAuth 2.0 scopes granted above, the application must also be assigned Okta admin roles. Navigate to the Admin roles tab and assign one of the following role combinations:

   Full data collection

   Assign the Super Administrator role to the application.

   The Super Administrator role is currently the only Okta admin role that allows reading application OAuth 2.0 grants and API service integrations, as the permissions corresponding to the okta.appGrants.read and okta.oauthIntegrations.read scopes cannot be delegated to custom admin roles. Assigning the Super Administrator role to the application does not pose a security risk, because its effective permissions are limited by the read-only OAuth 2.0 scopes granted above, so the OpenHound Okta collector cannot modify any data in the Okta organization.

   Least privilege

   If assigning the Super Administrator role is not acceptable in your environment, a less privileged combination of roles can be used instead, at the cost of the collector not being able to read application OAuth 2.0 grants and API service integrations.

   1. Assign the Read-only Administrator role to the application.

   2. As the Read-only Administrator role does not allow reading admin role assignments, create a custom admin role called IAM Readers with the View roles, resources, and admin assignments permission.

      

   3. Create a resource set called IAM Resources containing All Identity and Access Management resources.

      

   4. Assign the IAM Readers role to the application, scoped to the IAM Resources resource set.

      

   The permissions corresponding to the okta.appGrants.read and okta.oauthIntegrations.read scopes cannot be delegated to custom admin roles. With this role combination, the collector therefore cannot read application OAuth 2.0 grants or enumerate API service integrations. As a consequence, the oauth_scopes property of Okta_Application nodes will not be populated, and Okta_APIServiceIntegration nodes will be missing from the graph entirely. Because an application’s role permissions are filtered by its granted OAuth 2.0 scopes, attack path edges originating from OIDC applications will be missing from the graph as well.