Hello Community,
Here’s a practical guide to setting up Personal Authentication for ServiceNow integrations, using Azure DevOps as an example of a 3rd party system. This approach ensures that records are created under the identity of the logged-in user, not a generic system account — a key requirement for compliance and security.
Steps in Azure
1. Register ServiceNow in Azure AD
- Create a new app registration for ServiceNow.
- Create a client secret.
- Grant the necessary API permissions (e.g., user_impersonation for Azure DevOps).
Steps in ServiceNow
1. Create an Application Registry
- Set up authorization and token URLs.
- Use Authorization Code as the grant type.
- Add the hidden field Extend refresh token expiry and set it to true.
2. Configure OAuth Scopes
- Include the Azure DevOps [Application ID]/user_impersonation scope, get the application ID from the Azure DevOps application registration in Azure.
- Add offline_access to the scope with a space between two scope names. Like this “xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/user_impersonation offline_access”.
- Set Integration type to Personal so each user authenticates individually.
4. Create Connection & Credential Alias
- Define a new alias.
5. Create Connection
- Define a new connection.
- Populate the base URL.
6. Configure Flow Designer
- Flow Designer will handle token renewal automatically.
- For scripted integrations, implement your own token refresh logic.
- You cannot run tests on an action (because actions cannot run as the user who initiates the session). So create a flow or a subflow with the action to test it.
- Ensure the flow of a subflow runs as the user who initiates the session (not as system).
- The resource path for Azure DevOps should include the organization name and the project name as the two initial parts before “_apis”.
- Each user who wants to use the integration must explicitly log in and authorize via the Personal Integrations Dashboard.
8. Run the integration
- The goal of the integration with Personal Authentication is to make sure that records in the 3rd party tool are created using the identify of the user who authenticated in ServiceNow and provided the personal authentication permissions.
- You can see below that the user story in Azure DevOps is created using my identity, not the integration account (which is not used for this integration at all).
9. Manage Tokens
- Use the Manage Tokens interface to view or revoke user tokens.
- You are going to see an access token and a refresh token with validity dates.
10. Handle Errors
- If a user hasn’t authenticated, the flow will fail.
- Make sure to add error handling for missing tokens.
With this configuration, all actions in Azure DevOps are executed under the real user identity — giving you transparency, security, and auditability.
Has anyone else here already set up Personal Authentication for Microsoft integrations? Curious to hear your experiences or any pitfalls you encountered.
