Im having an asp.net web application using okta mfa verify. So Im using OICD application and I need to use client secret method to get authorisation token.
I attempted to retrieve an access token using the endpoint: https://integrator-8768245.okta.com/oauth2/v1/token
{
“error”: “invalid_client”,
“error_description”: “Only clients with ‘application_type’ of ‘service’ may use the client_credentials ‘grant_type’ with the Org Authorization Server.”
}
What is the correct way to obtain an OAuth 2.0 access token for Okta APIs without using an SSWS token?
Any guidance or best practices would be greatly appreciated.
You cannot use Client Secret auth when completing Client Credentials flow against the Org Authorization Server. This is deliberate on our part, as the Org Authorization Server is only intended to issue Access Tokens that protect Okta resources, not 3rd party resources, and as such requires use of Private Key JWT auth as a security measure to protect those Okta resources. In short, the Org Authorization Server is not designed to support M2M use cases
If you are instead trying to secure your own resource server, try updating your integration to instead point to a Custom Authorization Server, like the one named “Default.”
Note that you will have to create an Access Policy (allowing this specific client to use the server) and Access Rule (allowing client credentials flow to be used) before you will be able to use a custom authorization server. If you don’t, you will encounter a no_matching_policy error, as described here.
Thanks for the response. Just to add some context from my side:
I’m working on an ASP.NET web application that requires Okta Verify–based MFA for end users, which is why I’ve integrated the application as an OIDC (Web) application rather than a Service app. MFA is a hard requirement for this project.
In addition to user authentication + MFA, the application also needs to call Okta APIs (for example, users read) from the backend. For security and operational reasons, we are trying to avoid using long-lived SSWS API tokens and instead prefer an OAuth 2.0–based approach using client credentials (client_id + client_secret).
Given that MFA drives the need for an OIDC application, I wanted to confirm:
Is there any supported way to use an OIDC application (with Okta Verify MFA enabled) and still obtain OAuth access tokens for Okta APIs without SSWS, while using client_id / client_secret?
Or is Private Key JWT with a Service app the only supported OAuth option for accessing Okta APIs, even when the same project requires MFA for interactive users?
Yes, of course you can complete the OIDC login flow (either via redirecting to Okta or using one of our embedded SDKs) to get tokens that will work against Okta’s APIs (which means you should be using the Org Authorization Server). This is the set up described in our guide here: Implement OAuth for Okta | Okta Developer
However, note that only admins with appropriate admin roles/permissions granted will be able to use the access token they are granted against Okta’s API endpoint that require admin permissions (like listing users and groups in the org). An end-user would only be able to make requests for resources they can access without admin perms, like /api/v1/users/me and the myaccount endpoints
So if your application needs to make Okta API calls to manage resources in the org that will require admin permissions on behalf of end-users that are not themselves admins, you may still wind up needing to use a Service App to get tokens instead.
You didn’t clarify if the user you are requesting a token for is an Admin user or if they are an End User without any admin permissions.
I have to ask that as the Factors API endpoints you are referring to require Admin permissions to access and cannot be accessed using a token issued to an end-user. What is your reason to use these endpoints in the first place? Are you just trying to challenge users for MFA before letting them access your application or before attempting a more secure action within your application?
Our goal is not to manage organisational resources, but specifically to trigger an Okta Verify push challenge before allowing access to our ASP.NET application. We are trying to enforce MFA as an additional verification step within our application flow.
However, our project constraints:
We cannot redirect the user to Okta for authentication.
We cannot use SSWS API tokens (we are avoiding long-lived tokens).
We want to obtain an OAuth access token using only client_id and client_secret.
Using that token, we intended to call:
/api/v1/users/{id}/factors
/api/v1/users/{id}/factors/{factorId}/verify
Based on your explanation, it sounds like the Factors API requires admin-level permissions and therefore cannot be used with tokens issued to non-admin end users.
Given that our requirement is strictly to challenge end users with Okta Verify push (not to manage org resources), could you please advise what the recommended architecture would be in this case under these constraints?
Is manually calling the Factors API the wrong approach for enforcing MFA for end users, and should we instead be using a different authentication flow or SDK?
I’m not actually sure what it stands for, its just the string that needs to be included in the Authorization header when using a static API key (the ones generated in the Admin Console by navigating to Security → API → Tokens) .
If you use an OAuth access token instead (which we recommend over these static, long lived API keys), you will instead need to include 'Bearer ’ in front of the token in the Authorization header