--- sourceDocument: Yokohama Platform security sourceDocumentLink: https://www.servicenow.com/docs/r/yokohama/platform-security Release : - yokohama ft:locale : - en-US ft:publication_title : - Yokohama Platform security ft:clusterId : - psec bundleId : - psec workflow : - Platform --- # OAuth authorization code grant flow # OAuth authorization code grant flow {#ariaid-title1} * Release version: Yokohama * * Updated January 30, 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 authorization code grant flow The OAuth authorization code grant flow enables users to access resources by authenticating directly with an OAuth server trusted by the resource, avoiding the use of username/password credentials. This flow is implemented to allow secure REST API access where the client receives an authorization code via a configured URL, which it then exchanges for an access token. The user's credentials are never exposed to the client application requesting access. Show full answer Show less In ServiceNow, the instance itself can act as the OAuth authorization server issuing tokens during this flow. Users owning the restricted resources must explicitly authorize access and can revoke access tokens at any time. ## Authorization code grant flow process * **Step 1:** The client application initiates a GET request to the ServiceNow instance's authorization endpoint via the user agent, typically triggered by user interaction. The request includes the `responsetype=code`, `redirecturi`, `clientid`, and other OAuth parameters. The user must be logged into ServiceNow and will be prompted to Allow or Deny access. * **Step 2:** Upon user approval, the ServiceNow instance sends an authorization code to the specified redirect (callback) URL, which the client application receives. * **Step 3:** The client exchanges the authorization code for an access token by making a POST request to the token endpoint on the ServiceNow instance, providing the authorization code, client credentials, and redirect URI. The instance responds with an access token and a refresh token. The access token is then used by the client to authenticate REST API calls to ServiceNow, receiving data typically in JSON format. ## Key features and practical considerations * **Security:** The user's username and password are never exposed to the client application, enhancing security. * **Token management:** Access and refresh tokens can be managed and revoked within the ServiceNow instance. * **Integration support:** This flow supports integrations including Multi-SSO, SAML 2.0 Update 1, multifactor authentication, and the mobile interface. * **Configuration:** Clients must configure the authorization URL, token URL, client ID, client secret, and the redirect URI correctly to enable this flow. * **Alternative flows:** ServiceNow also supports OAuth implicit grant flows, but the authorization code grant flow is preferred for enhanced security. Authorization code grant flow allows a user to access a resource by authenticating directly with an OAuth server that trusts the resource, in contrast with authenticating with username/password credentials. This implementation of OAuth authorization code flow allows access to a resource via REST. The authorization code framework gets the access token through the authorized URL that the user configures rather than requiring the user to enter a username/password. The username/password are never exposed to the client that is requesting access to the resource. ## A ServiceNow instance as the authorization server The OAuth server is typically a third-party authorization server. You can also specify a ServiceNow instance as the authorization server that issues the tokens for authorization code flow. The user who owns the restricted resource must authorize access. The user can also revoke the issued access token at any time to terminate access. ## Authorization code grant flow process The Authorization code grant flow process consists of these three steps: In step one, the client application or website initiates a REST API call in the form of a GET request to the instance via the user agent. Typically, the REST call is initiated when the end user clicks a button or a link on the client application or website to request an access token. In the client application, the end user also has to specify the authorization URL, token URL, client ID, and client secret. For an explanation of these items, see the field descriptions in this topic: [Use a third-party OAuth provider](https://www.servicenow.com/docs/access?context=t_UseAThirdPartyOAuthProvider&version=yokohama&pubname=yokohama-api-reference&ft:locale=en-US). If the client asks for a grant type, the end user must select Authorization Code. Example GET request from the client application to the instance: https://myinstance.service-now.com/oauth_auth.do?response_type=code&redirect_uri={the_redirect_url}&client_id={the_client_identifier} Note: The response_type must be code to use the standard OAuth code grant flow. The end user must manually allow access to the restricted resource on the instance. In the ServiceNow implementation, the end user must be logged into the instance. The instance prompts the end user with a UI page that has Allow and Deny buttons. The item that the client application is actually requesting the token from is the OAuth provider application registry record that you created, also known as the authorization endpoint (see [Use a third-party OAuth provider](https://www.servicenow.com/docs/access?context=t_UseAThirdPartyOAuthProvider&version=yokohama&pubname=yokohama-api-reference&ft:locale=en-US)). The auth code is sent from the authorization endpoint to the client. It does not go to the client directly but to the Redirect URL that you specify on the authorization endpoint form. This URL is also known as a callback URL. You can obtain this URL from the client application or website. Example response from the instance to the client application, providing an authorization code: https/http://{callbackURL}?code={the actual auth code} Now that the client application has the authorization code, the client uses the code to request the access token. The authorization code proves that the user has consented in step 1. Example POST request from the client application to the ServiceNow instance that provides the auth code and requests the access token: https://myinstance.service-now.com/oauth_token.do?grant_type=authorization_code&code={the auth code}&redirect_uri={the_same_redirect_url}&client_id={the_same_client_identifier}&client_secret={client_secret_value} The endpoint on the instance returns an access token and a refresh token. The refresh token can be used to request additional access tokens. You can manage the tokens, including revoking the token, in the instance. See [Manage OAuth tokens](https://www.servicenow.com/docs/6~x9E1D1AV2LzwsPsKfJIA "Open OAuth tokens to provide access to restricted resources."). The client application uses the access token to authenticate to the REST API. After authenticating the client application, the REST API returns the requested data in a JSON payload. Example GET request for the JSON payload of data for the Incident \[incident\] table: https://myinstance.service-now.com/api/now/table/incident?access_token={the_token} Note: The system also supports [OAuth implicit grants](https://www.servicenow.com/docs/ZjjzV~lGul7ikRy~yGtJ4A "ServiceNow instances support the implicit grant of an access token."), also known as implicit grant code flow. ## Integration support Authorization code flow supports the following integrations on the instance: * Multi-SSO * SAML 2.0 Update 1 * Multifactor authentication {#c_OAuthAuthorizationCodeFlow__ul_ajz_jky_dw} The mobile interface is also supported.