<iframe src="https://www.googletagmanager.com/ns.html?id=GTM-M74D8PB" height="0" width="0" style="display:none;visibility:hidden">
Loading
Skip to NavigationSkip to Main Content
0D5KZ000014Annf0ACOkta Identity EngineWorkflowsAnswered2026-04-03T09:00:22.000Z2025-07-05T22:57:51.000Z2025-07-31T15:03:36.000Z

3dl5q (3dl5q) asked a question.

Okta Workflows HTTP Connector Auth

Hi there,

 

I'm currently stuck trying to generate an auth token in an API call using the HTTP Get function in Okta Workflows.

I'm able to get it working in Postman with the below Authorization parameters:

  • Auth Type - OAuth 2.0
  • Add authorization data to - Request Headers
  • Header Prefix - Bearer
  • Grant Type - Client Credentials (For the token)
  • Access URL - Correct OAuth URL
  • Client ID - Correct Client ID
  • Client Secret - Correct Client Secret
  • Client Authentication - Send as Basic Auth Header
  • Refresh Token - None (Unsupported by API)

And this is the main part that I'm not able to adapt to work on Okta Workflows' HTTP function API connector:

  • Token Request - key: client_id / Value: Correct Client ID
  • Token Request - key: client_secret / Value: Correct Client Secret
  • Token Request - key: grant_type / Value: client_credentials

 

I'd very much appreciate some feedback if any of you have dealt with the same issue.


  • TimL.58332 (Workflows)

    @3dl5q (3dl5q)​ - The built-in options are designed as a "One-size-fits-many" and not a "one-size-fits-all" as Workflows has no control over how third-parties decide to implement their authorization scheme. Even within common frameworks such as Oauth implementation / requirements can vary widely.

     

    Built-in inputs for API Connection > Client Credentials: (Note: From the connection Help, "Credentials are sent in the request body and not as a Basic authorization header.")

     

    image 

    If the built-in Client Credentials option will not work for this specific vendor's implementation you will need to leverage an auth "None" option and create each expected call per the vendor documentation. If the vendor documentation requires you to perform an action that Workflows cannot do (Like take a binary response and hash or encode it) then it will not be possible to create a connection with their endpoint.

     

     

     

    Expand Post
    Selected as Best
  • 3dl5q (3dl5q)

    I should also add the body is:

    --data-urlencode

     

    And the content type value in the header is: Content-Type: application/x-www-form-urlencoded

     

  • TimL.58332 (Workflows)

    @3dl5q (3dl5q)​ - The built-in options are designed as a "One-size-fits-many" and not a "one-size-fits-all" as Workflows has no control over how third-parties decide to implement their authorization scheme. Even within common frameworks such as Oauth implementation / requirements can vary widely.

     

    Built-in inputs for API Connection > Client Credentials: (Note: From the connection Help, "Credentials are sent in the request body and not as a Basic authorization header.")

     

    image 

    If the built-in Client Credentials option will not work for this specific vendor's implementation you will need to leverage an auth "None" option and create each expected call per the vendor documentation. If the vendor documentation requires you to perform an action that Workflows cannot do (Like take a binary response and hash or encode it) then it will not be possible to create a connection with their endpoint.

     

     

     

    Expand Post
    Selected as Best
This question is closed.
Loading
Okta Workflows HTTP Connector Auth