Event that is published in case an OAuth 2.0 Consent is granted or denied. This can happen in the following two scenarios:

1. Login: Initiated by an "OAuth 2.0 Consent Step", the user can either (depending on the configuration) explicitly grant consent directly in the flow (Local Consent), or grant consent on another system by being redirected (Remote Consent), or grant consent implicitly without interaction (No Consent). The event is published for any of these consent types. The event is not published in case the user denies access, leading to a flow termination or in case the scopes have been granted/declined previously (only if persistent consents are configured).
2. Self-Service: In case the scopes accepted and denied during login are persisted on the IAM (depends on the configuration), users can accept or deny them later in a protected self-service flow. The event is not published, in case the user deletes a consent.

The following information can be used under the corresponding key when consuming the event:

• event.data.oauth2.authorizationServerId Identifier of the OAuth 2.0 Authorization Server which has been involved when granting the consent.
• event.data.oauth2.clientId Identifier of the OAuth 2.0 Client which has been involved when granting the consent.
• event.data.oauth2.acceptedScopes The set of scopes which have been accepted by the user. May be empty.
• event.data.oauth2.deniedScopes The set of scopes which have been denied by the user. May be empty.
• event.data.oauth2.alwaysGrantedScopes The set of scopes which will always be granted. May be empty. These scopes never require explicit consent of the user. They can be derived from the configuration of the OAuth 2.0 Client and Authorization Server and are added here for convenience. Adding or removing always granted scopes from the configuration does not trigger events.

In order to subscribe only to a subset of the published events of this type, multiple filtering properties can be configured. Note:If several of these properties are configured, all conditions must be met.

Use Case 1: You want to handle all events of this type.
Use the default configuration.

Use Case 2: You want to handle events of this type, which have at least both of the accepted scopes email_verified and profile
Required values for Accepted Scopes Patterns: email_verified and profile
Handle Empty Accepted Scopes: false

Use Case 3: You only want to handle events of this type which have no denied scopes.
Required values for Denied Scopes Patterns: ^$
Handle Empty Denied Scopes: true

Use Case 4: You only want to handle events of this type if the consent has been given remotely.
The consent type (Local Consent, Remote Consent, No Consent) is determined by the configuration of the OAuth 2.0 Authorization Server and the OAuth 2.0 Client. Therefore, you can use their IDs for filtering.

Use Case 5: You only want to handle events of this type if the consent has been given during login and not as a self-service.
Use a "Filtered Flow Event" and filter for the corresponding flow type.

type: OAuth2UserConsentSubscribedEvent
id: OAuth2UserConsentSubscribedEvent-xxxxxx
displayName: 
comment: 
properties:
  acceptedScopesPatterns:
  alwaysGrantedScopesPatterns:
  authorizationServerIdPattern:
  clientIdPattern:
  deniedScopesPatterns:
  handleEmptyAcceptedScopes: true
  handleEmptyAlwaysGrantedScopes: true
  handleEmptyDeniedScopes: true