Integration Authentication Methods

Integration Authentication Methods in ServiceNow – Complete Guide for CAD Exam

Introduction

When ServiceNow communicates with external systems—or when external systems communicate with ServiceNow—authentication is the critical first step that ensures only authorized parties can access data and services. Understanding integration authentication methods is essential for the ServiceNow Certified Application Developer (CAD) exam, as it underpins how you securely connect ServiceNow to the outside world.

Why Is Integration Authentication Important?

Authentication in integrations serves several vital purposes:

• Security: It prevents unauthorized access to sensitive data and functionality. Without proper authentication, any system or user could potentially read, modify, or delete records.
• Compliance: Many organizations must comply with regulations (HIPAA, GDPR, SOX) that mandate secure data exchange between systems.
• Trust: Authentication establishes a chain of trust between ServiceNow and external endpoints, ensuring that both sides of the integration are who they claim to be.
• Accountability: Proper authentication allows you to audit and trace which system or user performed specific actions.
• Data Integrity: By restricting access to authenticated parties, you reduce the risk of data corruption or unauthorized manipulation.

What Are Integration Authentication Methods in ServiceNow?

ServiceNow supports multiple authentication methods for both inbound (external systems calling ServiceNow) and outbound (ServiceNow calling external systems) integrations. The primary methods include:

1. Basic Authentication
This is the simplest form of authentication. It sends a username and password encoded in Base64 as part of the HTTP request header.

• How it works: The client sends an Authorization header with the value Basic [Base64-encoded username:password].
• Use case: Quick integrations, development/testing environments, or when connecting to legacy systems that only support basic auth.
• Limitations: Credentials are only Base64-encoded (not encrypted), so it must always be used over HTTPS. It is considered less secure compared to other methods.

2. OAuth 2.0
OAuth 2.0 is a token-based authentication and authorization framework that allows third-party applications to access resources without exposing user credentials.

• How it works: ServiceNow can act as an OAuth provider (for inbound) or an OAuth client (for outbound). The process involves obtaining an access token (and optionally a refresh token) from an authorization server. The access token is then included in API requests.
• Grant Types supported by ServiceNow:
  - Authorization Code
  - Client Credentials
  - Resource Owner Password Credentials
  - Refresh Token
• Use case: Modern integrations with cloud services (e.g., Google, Microsoft, Salesforce), where delegated authorization is needed.
• Key concepts: Client ID, Client Secret, Access Token, Refresh Token, Token URL, Authorization URL.

3. Mutual Authentication (Mutual TLS / mTLS)
Mutual authentication requires both the client and server to present valid certificates to establish a trusted connection.

• How it works: Both parties exchange and validate X.509 certificates during the TLS handshake. This ensures that both sides are authenticated.
• Use case: High-security environments where both the calling and receiving systems must be verified, such as financial or healthcare integrations.
• Configuration: Requires uploading certificates in ServiceNow's certificate management (System Definition > Certificates) and configuring the REST or SOAP message to use mutual authentication.

4. API Key / Token-Based Authentication
Some external services require an API key or a static token to be passed in the request header or as a query parameter.

• How it works: A pre-generated key or token is included in every request. The receiving system validates the key.
• Use case: Simple external APIs that use API keys for access control.
• Implementation: Typically configured using HTTP headers in REST Message or SOAP Message records.

5. LDAP Authentication
While primarily used for user authentication, LDAP can play a role in integration scenarios where ServiceNow validates credentials against an external directory.

• How it works: ServiceNow connects to an LDAP server to authenticate user credentials during inbound API calls.

6. SSO / SAML (for Inbound)
SAML-based Single Sign-On can be relevant in integration contexts where browser-based authentication flows are involved.

• How it works: A SAML Identity Provider (IdP) authenticates users and provides a SAML assertion to ServiceNow.
• Note: SAML is more commonly associated with user login rather than system-to-system integrations.

How Authentication Works in Outbound Integrations

When ServiceNow sends data to an external system:

1. You create a REST Message or SOAP Message record.
2. In the message configuration, you specify the Authentication type (No authentication, Basic, OAuth 2.0, Mutual auth).
3. For Basic auth, you provide the username and password (or reference a credential record).
4. For OAuth 2.0, you configure an OAuth Entity Profile that points to an OAuth Provider application, which stores the Client ID, Client Secret, Token URL, and other OAuth parameters.
5. For Mutual auth, you upload and reference the appropriate certificates.
6. When the integration runs (via REST/SOAP message, Flow Designer, or scripted HTTP calls), ServiceNow includes the appropriate authentication credentials in the outbound request.

How Authentication Works in Inbound Integrations

When external systems call ServiceNow APIs:

1. The external system sends a request to a ServiceNow endpoint (Table API, Scripted REST API, Import Set API, etc.).
2. ServiceNow validates the authentication credentials provided in the request.
3. For Basic auth, ServiceNow checks the username and password against its user table (or LDAP).
4. For OAuth 2.0, ServiceNow validates the access token against its OAuth provider configuration.
5. The authenticated user's roles and ACLs determine what data and operations are available.

Credential Storage Best Practices

• Use Connection and Credential Aliases (part of the Integration Hub framework) to abstract credentials from the integration logic. This allows you to change credentials without modifying the integration.
• Store credentials in Credential records rather than hardcoding them in scripts.
• Use the Discovery Credentials table for MID Server-based integrations.
• Never store passwords in plain text in script fields or system properties.

Key ServiceNow Tables and Records

• OAuth Entity (oauth_entity): Stores OAuth provider or client configurations.
• OAuth Entity Profile (oauth_entity_profile): Links an OAuth entity to a specific grant type and credentials.
• Certificate (sys_certificate): Stores X.509 certificates for mutual authentication and other TLS purposes.
• REST Message (sys_rest_message): Outbound REST configuration including authentication settings.
• SOAP Message (sys_soap_message): Outbound SOAP configuration including authentication settings.
• Connection Alias (sys_connection_alias): Abstracts connection details for reusable integrations.
• Credential Alias (sys_credential_alias): Abstracts credential details for reusable integrations.

Common Exam Scenarios

The CAD exam may test your knowledge in the following ways:

• Choosing the correct authentication method for a given integration scenario.
• Understanding how to configure OAuth 2.0 as a provider or client.
• Knowing where to store and manage credentials securely.
• Understanding the difference between inbound and outbound authentication.
• Recognizing when mutual authentication is required.
• Knowing how Connection and Credential Aliases work in Flow Designer and Integration Hub.

---

Exam Tips: Answering Questions on Integration Authentication Methods

Tip 1: Know the Authentication Hierarchy
Understand that OAuth 2.0 is the preferred modern standard for secure integrations. If a question asks about the most secure or recommended method for cloud-to-cloud integrations, OAuth 2.0 is almost always the correct answer. Basic auth is the simplest but least secure option.

Tip 2: Distinguish Between Inbound and Outbound
Exam questions often specify the direction of the integration. For outbound integrations, focus on REST Message/SOAP Message authentication configuration. For inbound, focus on how ServiceNow validates credentials from external callers (user accounts, OAuth tokens, ACLs).

Tip 3: Remember OAuth Components
Be able to identify the key components: Client ID, Client Secret, Access Token, Refresh Token, Authorization Server URL, and Token URL. Know that an OAuth Entity Profile ties the configuration together in ServiceNow.

Tip 4: Understand Connection and Credential Aliases
These are increasingly important in the exam. Know that they allow you to decouple credentials from integration logic, making integrations more portable and maintainable across instances (dev, test, prod).

Tip 5: Mutual Auth = Certificates on Both Sides
If the question mentions that both the client and the server must verify each other's identity, the answer is mutual authentication (mTLS). Remember that this involves X.509 certificates.

Tip 6: Security Best Practices
Always choose answers that align with security best practices: use HTTPS, avoid hardcoded credentials, leverage credential records or aliases, and prefer OAuth over Basic auth when possible.

Tip 7: Process of Elimination
If you are unsure, eliminate answers that are clearly less secure or not applicable. For example, if a question describes a modern cloud API integration, eliminate LDAP and SAML (which are more user-focused) and focus on OAuth 2.0 or API key options.

Tip 8: Read the Question Carefully
Pay attention to keywords like external system calling ServiceNow (inbound) vs. ServiceNow calling an external system (outbound). Also look for terms like delegated authorization (OAuth), certificate-based (mutual auth), or username and password (basic auth).

Tip 9: Know the Default Behavior
By default, ServiceNow REST Messages and SOAP Messages support Basic authentication. OAuth must be explicitly configured. Understanding defaults helps you quickly identify correct configurations.

Tip 10: Practice with Real Configurations
If possible, set up an OAuth provider and client in a ServiceNow PDI (Personal Developer Instance). Hands-on experience with configuring authentication in REST Messages and seeing how tokens are exchanged will solidify your understanding far beyond memorization.

Summary

Integration authentication is a cornerstone topic for the ServiceNow CAD exam. You must understand the different methods (Basic, OAuth 2.0, Mutual Auth, API Keys), know when to use each, understand how they are configured in ServiceNow, and follow security best practices for credential management. Focus on OAuth 2.0 as the most commonly tested method, and always consider the direction (inbound vs. outbound) and security requirements of the integration scenario presented in each question.