Prevent OAuth Clients from Using Implicit Grant

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.

重要:

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: This URL fragment may be stored in the browser history. If the page subsequently loads images, or follows links to other domains, parts of the URL may leak via the referrer header. Web servers, load balancers, and proxies may log full URLs. 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 RFC 9700, "Best Current Practice for OAuth 2.0 Security" draft-ietf-oauth-v2-1-14, "The OAuth 2.1 Authorization Framework"
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. 注: 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