I have a web service that stores the Issuer URL, client ID and secret (or private key) to allow users to authenticate with Okta via OIDC. I want my service admins to be able to verify that the OIDC config stored in the service is correct.
For Azure EntraID I’m able to request the client token using the Client Credentials flow, and thus fully verify my service connection settings.
I was able to do the same thing with Okta using the Authorization Server, but my client doesn’t have this extra product (Okta API Access Management) and doesn’t intend to buy it, because they don’t need it. Is there any way that it can be done without it?
The following topic proposes an alternative, but I don’t get it. Is it described anywhere in detail?
The referenced article still mentions the Authorization Server, so it seems it doesn’t solve the issue:
Also the proposed solution would require a redirect in the browser, but that’s not acceptable. I want to verify the service credentials, not user credentials.
Creating a Service app also wouldn’t make any sense, as it would use different credentials.
What do you mean you want to verify that the config is correct? Are you just trying to validate that the Client ID provided is associated with their Okta org (Issuer), or are you also trying to test the Client Credentials (aka the secret)?
Why do you need to do this outside of testing the flow that will actually be used by your application to log users in? For instance, wouldn’t it be simplest to test the configuration when the details are supplied, and completing a redirect based flow in a pop-up to ensure you can get a token back for this user?
But for what purpose? The endpoints that will accept and validate client authentication are intended for specific purposes (e.g. to introspect or revoke tokens), there is not a dedicated endpoint to check creds alone.
@andrea The purpose is to verify the credentials. The standard OIDC token endpoint should support the grant_type=client_credentials parameter to return an access token for machine-to-machine communication.
Whether this token is then used or not, it’s not in the scope of this discussion. I just need a method to check if the credentials are correct. In this case, if creds are incorrect, the request returns an error.
This should be available for every OIDC app without having to buy the whole AM product which is not needed.
As you saw, you cannot complete Client Credentials flow against the Org Authorization Server with Client ID:Client Secret auth, as we only support using private_key_jwt for the only use case we support for Client Credentials flow + the Org Authorization Server: to get OAuth tokens that can be used against Okta’s APIs. See our docs for that here: Implement OAuth for Okta with a service app | Okta Developer
Due to this, I don’t see anyway to configure Okta to work the same as your Entra integration and be able to test the credentials outside of an OIDC flow.
Ah, I see. Though, what’s the rationale behind denying access with the client secret? Why not support both auth options? That would solve the problem, because our clients can choose how they want to authenticate the client, so verifying only one option would be inconsistent.