--- sourceDocument: Zurich Platform security sourceDocumentLink: https://www.servicenow.com/docs/r/zurich/platform-security Release : - zurich ft:locale : - en-US ft:publication_title : - Zurich Platform security ft:clusterId : - psec bundleId : - psec workflow : - Platform --- # OAuth 2.0 # OAuth 2.0 {#ariaid-title1} Release version: Zurich Updated July 31, 2025 ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 minutes to read Summarize ![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete. ## Summary of OAuth 2.0 OAuth 2.0 in ServiceNow enables secure access to instance resources by external clients via tokens instead of repeated login credentials. It requires thesecurityadminrole for configuration and supports two main scenarios: Show full answer Show less * **Inbound (OAuth external client scenario):** Your instance exposes endpoints for third-party clients to retrieve data. * **Outbound (OAuth provider scenario):** Your instance accesses data from third-party providers. Once authenticated initially to obtain a token, users do not need to reauthenticate until the token expires. OAuth 2.0 works with both simple and high security frameworks, with high security recommended for enhanced protection. ## Key Features * **Roles and Permissions:** Requires securityadmin role to manage OAuth integrations. * **Token-Based Access:** Uses access tokens with specific scopes and lifespans (default: 30 minutes for instance-issued tokens, 30 days for third-party tokens) and refresh tokens to renew access without reauthorization (default 100 days for instance tokens, 365 days for third-party tokens). * **OAuth Components:** * **Resource Owner:** User account granting access. * **Client:** Application requesting access on behalf of the user. * **Resource Server:** Hosts protected resources. * **Authorization Server:** Issues access tokens. * **Grant Types Supported:** * **Authorization Code:** Client obtains an authorization code before exchanging it for an access token (auth code flow). * **Resource Owner Password Credentials:** Client uses user credentials directly to get access tokens (password flow). * **Client Credentials:** Client uses client ID and secret configured in the application registry. * **Security Considerations:** * Self-signed certificates are not supported by ServiceNow AI Platform OAuth clients, ensuring trusted certificate usage. * OAuth client secrets are securely stored encrypted with Key Management Framework (KMF). * User passwords used for endpoint verification are stored as SHA-256 hashed values. ## Practical Implications for ServiceNow Customers By implementing OAuth 2.0, customers can enable seamless and secure integration between ServiceNow and third-party applications or services without exposing user credentials repeatedly. This enhances security, simplifies authentication management, and supports various authorization flows suited to different integration needs. High security settings are recommended to maximize protection. Understanding token lifespans and refresh mechanisms helps ensure uninterrupted access and compliance with security policies. OAuth 2.0 lets users access instance resources through external clients by obtaining a token rather than by entering login credentials with each resource request.{#c_OAuthApplications__ph_short-desc-oauth-2.0} You must have the security_admin role to manage the OAuth integration. Configure OAuth 2.0 for the following scenarios: * OAuth external client scenario (Inbound): Your instance provides an endpoint for third-party clients to pull data from the instance. * OAuth provider scenario (Outbound): Your instance pulls data from a third-party provider. {#c_OAuthApplications__ul_xfk_yzw_pr} Note: You must authenticate for the first time to fetch the token post which, you don't need to authenticate using a user account before the token expiry. Both, simple security and high security frameworks support OAuth 2.0. High Security is recommended. For OAuth 2.0 supported versions and how to activate high security, see [High Security Settings](https://www.servicenow.com/docs/MFHdO153qcYPc29qeM2a8A "High Security Settings refer to several security options available in your instance."). ## Key concepts of the OAuth 2.0 implementation {#c_OAuthApplications__table_jlt_dmv_yq__entry__2} | Concept | Description | |-|-| | Resource Owner | An entity capable of granting access to a protected resource. A resource owner who is a person is called an end user. The resource owner is always a user account. | | Client | An application that, with the authorization of the resource owner, makes requests for protected resources on behalf of the resource owner. | | Resource Server | The server that hosts the protected resources, capable of accepting and responding to requests for protected resources. | | Authorization Server | The server that issues access tokens to the client after successfully authenticating the resource owner and obtaining authorization. | | Authorization Request | The permission that a client requires to access a protected resource. The authorization request is always an HTTP POST message that contains the ID of the client that is acting on behalf of the resource owner and credentials that authorize the request. | | Authorization Grant | A credential that represents the authorization from the resource owner to access a resource. The authorization grant is either user login credentials or a refresh token. | | Access Token | A secure string that a client uses to access protected resources. An instance issues access tokens to clients that have a valid authorization grant. Each access token has a specific scope, lifespan, and other attributes. By default, an instance issues access tokens with a 30-minute lifespan in the scenario where the instance is the OAuth provider. For third-party tokens, 30 days. | | Refresh Token | A credential that a client uses to obtain new access tokens without requiring additional user authorization. An instance issues a refresh token to a client when it is first authorized to have an access token. By default, an instance issues refresh tokens with a 100-day lifespan in the scenario where the instance is the OAuth provider. For third-party tokens, 365 days. | | Self-signed certificates | The ServiceNow AI Platform does not support self-signed certificates. The OAuth client does not utilize the certificate trust store or allow connection to OAuth endpoints that incorporate a self-signed certificate. | | User agent | The user who delegates access rights to a client application, which is often a website. The access rights permit the client application or website to access data in the instance that the user has access rights to. The user agent is used in the scenario. | [ ] {#c_OAuthApplications__table_jlt_dmv_yq} ## OAuth grant types A grant type is the way that the client obtains the access token. The following grant types are supported: * Authorization code: The consumer first gets an authorization code and then uses it to get an access token. You can [Specify an OAuth profile](https://www.servicenow.com/docs/access?context=t_SpecifyAnOAuthProfile&version=zurich&pubname=zurich-api-reference&ft:locale=en-US) and specify this grant type. The process that uses the authorization code is also referred to as auth code flow or authorization code flow. * Resource owner password credentials: The consumer of the resource already has the user credentials to get the access token. This process is also referred to as password flow. * Client credentials: The consumer of the resource uses the client ID and client secret that is already configured in the application registry.{#c_OAuthApplications__client_credential} {#c_OAuthApplications__client_credential} {#c_OAuthApplications__ul_tlv_kxq_rs} ## Storage of authentication credentials The OAuth client secret is stored as a password2 type field, which is encrypted with KMF. User passwords, which are used to check incoming endpoint requests, are stored as a hash value in the User table in a password type field (SHA 256). For details on this encryption, see [Password2 encryption with KMF](https://www.servicenow.com/docs/c0dNyBoC1YF2iXg7waV6Cg "Supported by the Key Management Framework, use the Password2 (2-way encrypted) field type to encrypt and decrypt custom fields with segregation of duties, key protection, and life-cycle management. It works in accordance with NIST 800-57 guidelines and provides FIPS 140-2-L3 protection.")