OIDC - support for client credentials grant type!

Questions
#1

I want to understand why https://{{baseuri}}.okta.com/.well-known/openid-configuration
does not return client_credentials under grant_types_supported fields.

When I am in My API Manager Application trying to create a new client application, my API Manager is querying https://{{baseuri}}.okta.com/.well-known/openid-configuration to retrieve the list of grant types available and supported by okta.

Since OKTA is not returning Client Credentials grant type in https://{{baseuri}}.okta.com/.well-known/openid-configuration response, I have to login in OKTA and update the client application created manually, to add the client credentials grant type.

Any ideas on how to configure okta to accept client_credentials Out of the box for OIDC?

(We know that https://{{baseURI}}.okta.com/oauth2/default/.well-known/oauth-authorization-server returns client_credentials under grant_types_supported.)

#2

The Org authorization server, the one associated with https://{{baseuri}}.okta.com/.well-known/openid-configuration does not support the client_credentials flow. Client Credentials flow requires that a custom scope be created and thus you must use a custom authorization server (such as the one called Default, which is the first custom authorization server available in orgs with the API Access Management feature), as mentioned here.

#3

I will try that in my official org… but just to let you know, it did not work in my dev org.

#4

Hi Andreas, thanks for your response.

Unfortunally, it did not work:

  • we made our own auth server
  • we create a scope
  • we give it default, show in medatata and Require user consent for this scope were set on .

if we go to:https://{{uri}}.oktapreview.com/oauth2/a{{*****}}7/.well-known/openid-configuration

we still got:
image

Any other ideas?

Thank you in advance.
L. Bitencourt

#5

You can only see client_credentials listed as a supported grant type on the OAuth server metadata endpoint because OIDC does not support the client credentials flow. OIDC flows will always involve a user, but client_credentials is used for machine-to-machine flows and does not involve a user.

If you are using client_credentials flow, you should use the OAuth discovery endpoint instead of the OIDC one.

#6

Yeah, that makes sense, but since ones can manually login in okta and update the client application to acept client credentials (and everything works after the manual update), the client credentials should be available as an option in my client.

I will be probably forced to use another product as client id provider or create some batch job that updates client applications in okta every 30 secs or so to make sure they have client credentials :frowning:

Anyway, thank you for your help and clarifications.

Leo Bitencourt

#7

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.