One gap that continues to stand out in Identity Security Cloud (ISC) is the inconsistent OAuth token handling between the ServiceNow Governance Connector and the ServiceNow Service Desk Connector—specifically around refresh token retrieval and management.
The ServiceNow Service Desk Connector is able to retrieve and store its own refresh token as part of the OAuth flow. This allows the connector to renew access tokens autonomously and maintain long‑term, uninterrupted operation without manual intervention.
By contrast, the ServiceNow Governance Connector does not support retrieving or managing its own refresh token. Instead, it requires a static token or external token management, even though it relies on the same underlying ServiceNow OAuth framework and operates against the same platform.
This raises several concerns:
-
Architectural inconsistency
Both connectors integrate with ServiceNow and leverage OAuth 2.0, yet only one is implemented in a fully token‑aware, self‑renewing manner. From a platform consistency perspective, this is difficult to justify. -
Operational risk and overhead
Without refresh token support, the Governance Connector introduces operational fragility—tokens expire, access breaks, and manual remediation is required. This undermines reliability for scheduled aggregation, provisioning, and governance jobs. -
Security posture
Ironically, the lack of refresh token handling often leads teams to rely on long‑lived or manually managed tokens, which is generally worse from a security standpoint than short‑lived access tokens backed by refresh tokens. -
Customer experience and expectations
Customers reasonably expect similar ServiceNow integrations within the same product to follow consistent authentication patterns. When one connector handles OAuth “correctly” and another does not, it creates confusion and erodes trust in the connector architecture.
If there is a technical limitation, ServiceNow API constraint, or historical design decision driving this behavior, it would be helpful to document it clearly. Otherwise, this feels like technical debt that should be addressed by bringing the Governance Connector in line with the Service Desk Connector’s OAuth implementation.
At minimum, clarity on why this disparity exists—and whether there is a roadmap to close the gap—would go a long way for customers building secure, low‑maintenance ServiceNow integrations in ISC.
Questions for discussion:
-
What specific limitation prevents the Governance Connector from retrieving and storing its own refresh token?
-
Is this a known roadmap item or a deliberate design decision?
-
Are there plans to standardize OAuth behavior across ServiceNow connectors in ISC?
Interested to hear others’ experiences or any official guidance on this.