--- sourceDocument: Australia Platform security sourceDocumentLink: https://www.servicenow.com/docs/r/platform-security Release : - australia ft:locale : - en-US ft:publication_title : - Australia Platform security ft:clusterId : - psec bundleId : - psec workflow : - Platform --- # Prevent OAuth Clients from Using Implicit Grant # Prevent OAuth Clients from Using Implicit Grant {#ariaid-title1} Release version: Australia Updated March 12, 2026 ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 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 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 {#sc-prevent-oauth-clients-from-using-implicit-grant__section_k2s_p4k_4hc} {#sc-prevent-oauth-clients-from-using-implicit-grant__table_ajc_b43_3kb__entry__2} | Attribute | Description | |-|-| | Configuration name | glide.oauth.clients.allowed.for.implicit.grant | | Configuration type | System Properties (/sys_properties_list.do) | | Data type | String | | Recommended value | \ | | Default value | \ | | Fallback value | \ | | Category | [API and web service](https://www.servicenow.com/docs/qD0xNDqwckf2rLNMfnkZ5g "The API and Web Service category ensures that applications have appropriate authentication, authorization and session management, validate all input that traverses a trust boundary and include security controls for all API types.") | | 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. {#sc-prevent-oauth-clients-from-using-implicit-grant__ol_zmx_btk_4hc} 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 * [RFC 9700, "Best Current Practice for OAuth 2.0 Security"](https://datatracker.ietf.org/doc/html/rfc9700#name-implicit-grant) * [draft-ietf-oauth-v2-1-14, "The OAuth 2.1 Authorization Framework"](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-14#name-removal-of-the-oauth-20-imp) {#sc-prevent-oauth-clients-from-using-implicit-grant__ul_gf2_htk_4hc} {#sc-prevent-oauth-clients-from-using-implicit-grant__ul_g1g_3sf_xwb} | | 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 | [ ] {#sc-prevent-oauth-clients-from-using-implicit-grant__table_ajc_b43_3kb}