Join the #BuildWithBuildAgent Challenge! Get recognized, earn exclusive swag, and inspire the ServiceNow Community with what you can build using Build Agent.  Join the Challenge.

OAuth 2.0 client_credentials token returns "User is not authenticated" for Table API (PDI)

MahenG
Mega Contributor

Hi all,

 

I’m trying to configure an OAuth 2.0 client_credentials-based integration on my personal developer instance (PDI).

 

Goal
Use grant_type=client_credentials to obtain an access token from my PDI and then call the Table API (/api/now/table/*) from an external app.

 

What I've configured so far

In Global scope (sys_properties.list):

  • Property name: glide.oauth.inbound.client.credential.grant_type.enabled

  • Type: true/false

  • Value: true

OAuth API endpoint (Application Registry, Global)

In System OAuth → Application Registry, I created a record:

  • Application: Global

  • Name: App OAuth Client (Client Credentials)

  • OAuth Application User: app_integration (dedicated integration user)

Integration user & roles

User: app_integration
Roles assigned:

  • rest_api_explorer

  • snc_platform_rest_api_access

  • snc_read_only

  • rota_manager

  • itil

Using the REST API Explorer while logged in as a normal admin user, I can successfully call:

  • /api/now/table/incident

  • /api/now/table/sys_user

so ACLs for those APIs look fine for a standard user session.

 

Created a New Inbound Integration (grant type: client_credentials).

Created an Inbound Authentication Profile of type OAuth, referencing the OAuth client.

Created a REST API Access Policy for Table API and attached that auth profile.

 

Token issuance (works)

From an external client, I call:

curl --location 'https://devXXXXX.service-now.com/oauth_token.do' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'grant_type=client_credentials' \
--data-urlencode 'client_id=CLIENT_ID' \
--data-urlencode 'client_secret=CLIENT_SECRET'

 

The response is:

{
  "access_token": "<redacted_token>",
  "scope": "",
  "token_type": "Bearer",
  "expires_in": 1799
}

 So oauth_token.do is issuing a Bearer token correctly using grant_type=client_credentials.

 

Table API call (fails with "User is not authenticated")

Using that access token, I call:

curl --location 'https://devXXXXX.service-now.com/api/now/table/incident?sysparm_limit=1' \
  --header "Authorization: Bearer <redacted_token>" \
  --header "Accept: application/json"

 The response is:

{
  "error": {
    "message": "User is not authenticated",
    "detail": "Required to provide Auth information"
  },
  "status": "failure"
}

So the platform is minting a token, but the Table API is not treating the Bearer token as valid authentication.

 

On a PDI (Zurich), is there any additional configuration or known requirement for making client_credentials tokens from an Application Registry OAuth client (with OAuth Application User set) work as valid authentication for the Table API?

1 REPLY 1

daisy82lope
Kilo Contributor

I’m trying to configure an OAuth 2.0 client_credentials integration on my personal developer instance (PDI) to obtain an access token and securely call the Table API from an external application. I enabled the glide.oauth.inbound.client.credential.grant_type.enabled property, created an OAuth Application Registry entry in the Global scope, and assigned the integration user (app_integration) roles including

 rest_api_explorer, snc_platform_rest_api_access, snc_read_only, rota_manager, and itil. Using the REST API Explorer as an admin, I can successfully access incident and sys_user tables, confirming that ACLs are not the issue. I then created an Inbound Integration using the client_credentials grant type, configured an Inbound OAuth Authentication Profile, and attached it to a REST API Access Policy for the Table API. Token issuance works successfully—oauth_token.do returns a valid Bearer token—but when I attempt to call the Table API with that token, ServiceNow returns a “User is not authenticated” error, indicating that the token is not being treated as valid authentication. I’m trying to determine whether PDIs running the Zurich release require additional configuration for client_credentials tokens created via the Application Registry (with OAuth Application User set) to function properly with the Table API.