We’re migrating our Pritunl connectors to use Okta MFA instead of Duo MFA. However, I’ve found that to trigger MFA push notifications correctly, you need an Admin API token rather than a read-only token. I’m trying to avoid generating Super Admin API tokens and leaving them lying around. Ideally, I want to create a dedicated service account for Pritunl with the minimum required permissions or, at least, a new admin role with limited scope.
I’m looking for insight into which specific scopes are needed in Okta to successfully initiate the Okta Verify push notifications. Unfortunately, a read-only token isn’t sufficient in this case, and I’m not sure which specific scope the API requires to trigger the push to the user’s Okta Verify app.
Thanks, Zach — yeah, that’s what I’m seeing too. But just to clarify, it’s not that I’m trying to avoid giving any write access; the issue is that in order to trigger the Okta Verify push via API, it seems like I need to use a full system admin token per Pritunl connector. For some orgs, that could mean having a large number of highly privileged API tokens scattered across infrastructure, which is obviously not ideal from a security perspective.
What I’m hoping to figure out is whether there’s a way to scope down that token—either by creating a service account with just the required permissions or assigning it a custom admin role that limits access to just what’s necessary to trigger the MFA push. Even a clear list of required scopes would help.
Has anyone had success doing something like this with custom admin roles in Okta?
I did look through documentation, there may be an OAuth API that has scopes to provide limited access to user accounts. But this doesn’t appear to have functionality to trigger push authentication without the user present.
This may be able to be accomplished by configuring single sign-on connection authentication then configuring Okta to require a secondary approval for every login.
A better option for secondary authentication is to configure device authentication which will use the TPM or Secure Enclave on the device without needing user interaction. This also has no risks of phishing attacks or users approving unknown push requests. All Windows 11 devices and most modern macOS devices will have a TPM or Apple Secure Enclave.
We’re currently working with Okta support to investigate this issue related to device push authentication. As part of their guidance, I performed a test this morning using Postman to validate the API token functionality.
Using a Custom Admin Role API token I was able to:
Successfully send a GET request to retrieve the Okta Verify Push factor ID
Successfully send a POST request to trigger a push notification to my device
Both requests worked as expected, and I received the push notification on my phone — confirming that the token is valid and has the necessary permissions for these operations.
However, when attempting to use this same API token within our Pritunl VPN configuration, the connection fails. So while the token is functioning properly via direct API calls, it doesn’t appear to be accepted in the VPN context.