Workflow HTTP Operation 401 JWT Required

Hi all,

I have a scheduled workflow that I am currently triggering manually for testing. It is a simple Workflow that will hit only one ISC endpoint via an HTTP Operation action. What I’m running into right now is an HTTP 401 “JWT is required” error. I have my one HTTP Operation configured to use OAuth2 client credentials grant flow. My token URL is: https://.api.identitynow.com/oauth/token, my clientId and clientSecret are validated to work via Postman. My credential location is header, my scope is blank, my request headers are “Accept”: “application/json”.

Is there any additional configuration needed for this? I thought the bearer token would get generated and passed after hitting the OAuth endpoint into my request headers automatically. Do I need to reference the token or prep the headers with “Authentication”: “Bearer” or anything like this?

Also worth noting is I have tried setting my token URL to https://.api.identitynow.com/oauth/token?grant_type=client_credentials and this also did not work.

Hey !

Make sure the user actually have the accffess to do the operation/requested URL.
Can you attache the workflow for us to see and help you?

Best!

Hi Ivan,

Please see the bit above where I have validated the clientId and clientSecret. I have pasted a stripped down version of the workflow code below. I basically am just looking to see if I need to be doing anything special or if the OAuth client credentials flow should be handling the authentication for my HTTP request automatically. If so, then this is likely a bug.

{
    "id": "<id>",
    "name": "test wf",
    "description": "",
    "definition": {
        "start": "HTTP Request",
        "steps": {
            "End Step - Success": {
                "displayName": "",
                "type": "success"
            },
            "HTTP Request": {
                "actionId": "sp:http",
                "attributes": {
                    "authenticationType": "OAuth",
                    "method": "get",
                    "oAuthClientId": "<validClientId>",
                    "oAuthClientSecret": "<validClientSecret>",
                    "oAuthCredentialLocation": "oAuthInHeader",
                    "oAuthScope": null,
                    "oAuthTokenUrl": "https://<tenant>.api.identitynow.com/oauth/token",
                    "requestContentType": "json",
                    "requestHeaders": {
                        "Accept": "application/json"
                    },
                    "url": "https://<tenant>.api.identitynow.com/v3/roles"
                },
                "displayName": "HTTP Action",
                "nextStep": "End Step - Success",
                "type": "action",
                "versionNumber": 2
            }
        }
    },
    "enabled": false,
    "executionCount": 1,
    "failureCount": 1,
    "trigger": {
        "displayName": "Every 2 hours at 30 mins after",
        "type": "SCHEDULED",
        "attributes": {
            "cronString": "30 */2 * * *",
            "frequency": "cronSchedule",
            "timeZone": "America/Chicago"
        }
    }
}

I know may sound strange but, try to remove the Header " Accept Json"

Best

I have removed the “Accept” header and reran my test. I still receive the same error message:

{
        "type": "WorkflowExecutionFailed",
        "attributes": {
            "error": "actionStep(HTTP Request) Err: task failed: activity error (type: sp:external:http:v2, scheduledEventID: 5, startedEventID: 6, identity: <id>): request failed (type: HTTP Response Returned a Client Error, retryable: false): request failed: 401 - 401 Unauthorized - {\"error\":\"JWT is required\"}"
        }
    }

Hi @dominick-miller ,

The workflow script you gave here is working fine. Check for the user scope.

Just build it your workflow on my Dev tennant and its working fine.

Maybe if you check the user Scope, yes the user who owns the workflow must have access to execute the steps.
Now theres other place you could be receiving this error from?

This makes no sense. I am using the client credentials for my PAT and I am an org admin with all scopes. Good to know that my underlying workflow is fine, but I am concerned with why I cannot execute a seemingly basic workflow in my sandbox tenant as org admin with all scopes.

Hey Dominnick i know is frustrating. Lets try another thing.

Create a new ClientID and Secret with sp:scope:all put in the workflow and try again.
It seems to be Access problem.

I have tried this and received the same error. What I am seeing in the error message above is scheduledEventID: 5, startedEventID: 6. Do you know what this corresponds to? There are less than 5 events in my workflow.

@colin_mckibben do you know of any Workflow limitations for client credentials? I was able to narrow this down and found that I am able to hit endpoints that do not require org_admin permissions using credentials generated via API Management. However, I receive a 401 when trying to use my own org_admin PAT credentials (I am also the workflow owner - not sure if this matters) to hit an API via the workflow. This same endpoint can be hit successfully via Postman using the same org_admin PAT credentials.

Hi @dominick-miller,

Do you use Personnal access token (PAT) or Oauth client ?

If it’s PAT i suuggest you to generate Oauth clients with client credential grant and test it.

Best regards.

That 401 “JWT is required” error happens when either the clientId and secret are missing, or not complete. I suggest you delete the HTTP Action and configure a new one.

@colin_mckibben I have deleted/recreated the HTTP action and created entirely new workflows and am observing the same behavior across all attempts.

To summarize:

  1. ClientId & ClientSecret are not missing and are complete. They are, in fact, validated via Postman and I am hitting the same SailPoint endpoint as within the workflow.
  2. PAT clientId & clientSecret (the same as (1)) do not work inside the SailPoint workflow. I receive a 401 JWT is required error. This is true for endpoints designated as requiring org_admin permissions and endpoints not requiring org_admin permissions.
  3. When generating a new PAT (scoped for all) and using inside the SailPoint workflow, I still receive a 401 JWT is required error.
  4. When generating a token via API Management (not scoped for org_admin as this is a technical limitation of SailPoint) I receive a 403 unauthorized error for the org_admin endpoint and a 200 successful for the non-org_admin endpoint. This is expected behavior.

Therefore, these steps 1-4 lead me to conclude the following: There is either a bug within SailPoint where workflows cannot use PATs to hit internal endpoints OR this is intentional, in which case it is impossible to hit certain endpoints which require org_admin permissions via SailPoint workflows (since we cannot scope ‘general’ tokens to have org_admin permissions).

There is, of course, a third possibility where my sandbox instance is corrupt and is causing this strange behavior but I would like to verify that the two possibilities above are not true before coming to this conclusion.

Please let me know your thoughts.

I tested PAT in my org and it works. I could only replicate your issue by deleting some characters from my client ID or by removing it altogether. This appears to be environment specific, in which case you should open a support ticket. Support has the means to investigate your tenant more closely to diagnose the issue.

Okay, this is good to know. There must be something strange going on in my sandbox environment. Thank you for the sanity check. I have opened a support ticket.

Thanks Dominick. Don’t forget to report back here when you get a resolution from support. It could help others to hear what the resolution was.

Hi @dominick-miller,

For following test :
" 4. When generating a token via API Management (not scoped for org_admin as this is a technical limitation of SailPoint) I receive a 403 unauthorized error for the org_admin endpoint and a 200 successful for the non-org_admin endpoint. This is expected behavior."

What do you mean by : “not scoped for org_admin as this is a technical limitation of SailPoint” ?

This not work also for your http request action in your workflow ?

SailPoint does not allow you to generate tokens via the API Management screen that have full capabilities. Even if you go to API Management > Generate new token > give it all scopes, there are some endpoints (quite a few, actually) that require ORG_ADMIN permissions to execute. So even if you have sp:scope:all you cannot execute certain endpoints.

1 Like

Hi All,

I’ve tried as well. All works with Postman

curl command:

curl --location --request POST 'https://<tenant>.api.identitynow.com/beta/sources/<SOURCEID>/load-accounts' \
--header 'Authorization: Bearer <REDACTED>' \
--header 'Content-Type: application/json' \
--data-raw '{
    "disableOptimization": true
  }'

However, my test workflow does not:

{
	"name": "TEST",
	"description": "",
	"modified": "2024-05-24T17:04:39.869109823Z",
	"modifiedBy": {
		"type": "IDENTITY",
		"id": "<REDACTED>",
		"name": "<REDACTED>"
	},
	"definition": {
		"start": "HTTP Request",
		"steps": {
			"End Step - Success": {
				"displayName": "",
				"type": "success"
			},
			"HTTP Request": {
				"actionId": "sp:http",
				"attributes": {
					"authenticationType": "OAuth",
					"jsonRequestBody": {
						"disableOptimization": true
					},
					"method": "post",
					"oAuthClientId": "<REDACTED>",
					"oAuthClientSecret": "$.secrets.<REDACTED>",
					"oAuthCredentialLocation": "oAuthInHeader",
					"oAuthTokenUrl": "https://<REDACTED>.api.identitynow.com/oauth/token",
					"requestContentType": "json",
					"requestHeaders": {
						"Content-Type": "application/json"
					},
					"url": "https://<REDACTED>.api.identitynow.com/beta/sources/86cb9b1cfb9842089cd182a20df2544e/load-accounts"
				},
				"description": null,
				"displayName": "Unoptimized Aggregation",
				"nextStep": "End Step - Success",
				"type": "action",
				"versionNumber": 2
			}
		}
	},
	"creator": {
		"type": "IDENTITY",
		"id": "<REDACTED>",
		"name": "<REDACTED>"
	},
	"trigger": {
		"type": "SCHEDULED",
		"attributes": {
			"cronString": "30 */2 * * *",
			"frequency": "cronSchedule",
			"timeZone": "America/Chicago"
		}
	}
}

In case it helps, Dominick and I are in Frankfurt eu-central-1

It would be very helpful if there were a way for us to get a meaningful error message or view the request response