OAuth2 App Consent Granted
Webhook Event: Starts flow when an OAuth2 App is granted consent by a user in Okta.(app.oauth2.as.consent.grant)
|Date and Time
|Date and time the event was triggered in Okta API.
|Message details about the event.
|Event's unique identifier key.
|Type of event that was published.
|Timestamp when the notification was delivered to the service.
|Unique identifier of the Okta actor who granted the consent.
|Email address of the Okta actor.
|Display name of the Okta actor.
|Type of Okta actor
|Unique identifier of the scope granted.
|Display name of the scope granted.
|Type of the scope granted.
|Details of the scope granted.
|Webhook event's universal unique identifier.
|Raw JSON payload returned from the Okta API for this particular event.
|Object representing the headers for the response; each key of the header will be parsed into a header string as "key: value" (Content-Type: text/plain).
|Source of user-specific data.
|Information on the triggered event used for debugging. For example, returned data can include a URI, an SMS provider, or transaction ID.
While you can create additional user or group fields for an Okta event, the Okta API only returns values for four fields: ID, Alternate ID, Display Name, and Type.
No other fields are supported for users or groups, and data from such fields isn't returned by this event card.
Currently OAuth Consent works only with a custom authorization server. Okta provides a pre-configured custom authorization server called default. It includes a basic access policy and a rule to quickly get you started. For simple use cases, this out-of-the-box custom authorization server is usually all that you need. The user can also create and configure their own authorization server.
In order to use custom authorization servers, Okta's API Access Management product must be enabled for the org. That means enabling the following feature flags:
If it’s an OIE org, the following feature flag must also be enabled.