Insecure OAuth2.x flows have been enabled for some applications

title: Insecure OAuth2.x flows have been enabled for some applications
id: 7b4ec6f9-fdae-4e35-8c5c-8daaf473220c
status: experimental
description: |
    Detect when applications' configurations have been updated with insecure grant types, e.g. implicit and resource owner password grant.
    According to the recent update OAuth2.1 and RFC 9700, these flows shall be avoided.
author: Okta
date: 2025-07-11
modified: 2025-09-17
logsource:
    product: auth0
detection:
    selection:
        data.type: sapi
        data.description:
            - Update a client
        data.details.response.statusCode: 200
    filter:
        data.details.response.body.grant_types{}:
            - 'implicit'
            - 'password'
    condition: selection and filter
explanation: >
    The query collects log records issued when any of the configurations for an application are updated.
    It filters for grant types if it contains implicit and/or password (Resource Owner Password Grant).
    The Splunk query below takes the last update of settings for each application/client.
    It alerts those where implicit and/or resource owner grants are present in the last modification, thus active settings.
    The query displays modifying IP and modified client_id where insecure grants have been enabled.
splunk: |
    index=auth0 data.tenant_name="{your-tenant-name}"
    data.type=sapi data.description="Update a client"
    data.details.response.statusCode=200
    ```Limiting to critical appllications```
    ```data.details.response.body.client_id IN ('{critical-client_id-1}', '{critical-client_id-2}')```
    | fields _time, data.ip, data.details.response.body.client_id, data.details.response.body.grant_types{}
    ```Take only the last change of configurations that reflects the current settings```
    | sort -_time, data.details.response.body.client_id
    | dedup data.details.response.body.client_id
    | spath path=data.details.response.body.grant_types{} output=allowed_grants
    | where allowed_grants IN ("implicit", "password")
    ```Display the information in a table```
    | table _time, data.ip, data.details.response.body.client_id, data.details.response.body.grant_types{}
comments:
    - The Splunk query above shall be tuned to reflect a valid tenant name.
    - Limit this detection to monitoring a critical set of applications.
    - This Splunk query can be adjusted to report the actual configurations for all applications by removing the "where" clauses.
tenant_logs: |
    type:"sapi" AND description: "Update a client"
prevention:
    - Control tenant admins, i.e. "Admin", as this role has permissions to modify any application.
    - Control Management API scopes that allow modification of client's settings - update:clients.
    - Control usage of Management API from only trusted IPs by applying Network ACL scoped to "management".
    - If you have an edge case where the implicit flow is necessary, use a better version of it - request a token via the form_post
      response mode; request only ID token in combination with a code (Hybrid); request access token in a combination with an ID token
      protected from reply attacks by nonce for matching the at_hash attribute.
    - Default to the Authorization Code grant with PKCE even for regular web applications enforcing PKCE with a post-login action.
falsepositives:
    - Legitimate updates by an administrator. This rule is designed for threat hunting and to be a starting point for further investigation.
    - An exempted application has been updated with insecure grant types. It is still not recommended to use these flows.
level: medium
tags:
    - attack.defense-evasion
    - attack.t1562
    - attack.t1562.007