Prevent OAuth Clients from Using Implicit Grant

  • Release version: Australia
  • Updated March 12, 2026
  • 2 minutes to read
    • Summarize
    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 Prevent OAuth Clients from Using Implicit Grant

    To enhance security, ServiceNow allows users to prevent OAuth clients from utilizing the implicit grant type. The implicit grant was originally developed to address limitations with browser and client-side applications, but due to improvements like Cross Origin Resource Sharing (CORS), its use is no longer necessary and poses security risks.

    Show full answer Show less

    Key Features

    • System Property Control: Utilize the glide.oauth.clients.allowed.for.implicit.grant property to restrict the use of the implicit grant type. Ensure this property is either absent or has no value.
    • Security Risks: The implicit grant type can lead to access token leakage and replay attacks, as tokens are included in URL fragments that may be logged or exposed.
    • Fallback Behavior: Implicit grant requests will fail by default unless specifically allowed by the configuration.
    • Recommended Grant Type: Use the authorization code grant type for improved security when delegating authorization.

    Key Outcomes

    By implementing these changes, customers can significantly reduce security vulnerabilities related to OAuth token handling. If no OAuth clients are configured to use the implicit grant type, there will be no adverse effects from this configuration. Adapting existing OAuth clients to a different grant type may require modifications outside of the ServiceNow platform.

    Use a system property to avoid the use of the implicit grant type.

    The OAuth implicit grant was created to overcome a limitation between browsers and client-side applications (for example, single page applications) prior to the widespread adoption of Cross Origin Resource Sharing (CORS). Specifically, browsers' same-origin policy blocked the request that exchanged the OAuth authorization code with the OAuth access token. Since CORS support is universal, OAuth clients don’t need to use the implicit grant, and implicit grant type requests fail by default.

    Client IDs listed in the glide.oauth.clients.allowed.for.implicit.grant property can continue using the implicit grant type. Ensure that the property doesn’t exist in the System Properties [sys_properties] table, or exists but doesn’t contain a value.

    Important:
    Changing an OAuth client to a different grant type may require code or configuration changes in the client application (outside of the ServiceNow platform).

    More information

    Attribute Description
    Configuration name glide.oauth.clients.allowed.for.implicit.grant
    Configuration type System Properties (/sys_properties_list.do)
    Data type String
    Recommended value <blank>
    Default value <blank>
    Fallback value <blank>
    Category API and web service
    Security risk
    • Severity score: 3.9
    • CVSS score: low
    • Security risk details:

      The OAuth implicit grant type causes the authorization server to issue access tokens within the authorization response, making it vulnerable to access token leakage and access token replay. This means that an attacker can use the leaked or stolen access token at a resource endpoint.

      In the implicit grant, the authorization server returns an access token directly in the URL fragment, potentially causing problems:

      1. This URL fragment may be stored in the browser history.
      2. If the page subsequently loads images, or follows links to other domains, parts of the URL may leak via the referrer header.
      3. Web servers, load balancers, and proxies may log full URLs.
      4. Any JavaScript running on the page (including malicious, injected JS) can read the window.location.hash and extract the token.

      To avoid these issues, use the authorization code grant type rather than the implicit grant type when a human/interactive user is delegating authorization to the client.

      References
    Functional impact

    The implicit grant type request fails out of the box. Any OAuth clients with the implicit grant type that aren’t added to the property fail by default.

    If you haven't defined any OAuth clients that use the implicit grant type, there is no impact.

    Note:
    Changing an OAuth client to a different grant type may require code or configuration changes in the client application (outside of the ServiceNow platform).
    Dependencies and prerequisites None