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.||String|
|Message||Message details about the event.||String|
|Event ID||Event's unique identifier key.||String|
|Event Type||Type of event that was published.||String|
|Event Time||Timestamp when the notification was delivered to the service.||String|
|ID||Unique identifier of the Okta actor who granted the consent.||String|
|Alternate ID||Email address of the Okta actor.||String|
|Display Name||Display name of the Okta actor.||String|
|Type||Type of Okta actor||String|
|ID||Unique identifier of the scope granted.||String|
|Display Name||Display name of the scope granted.||String|
|Type||Type of the scope granted.||String|
|Detail Entry||Details of the scope granted.||String|
|UUID||Webhook event's universal unique identifier.||String|
|Event Details||Raw JSON payload returned from the Okta API for this particular event.||Object|
|Headers||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).||Object|
|Source||Source of user-specific data.||String|
|Debug Data||Information on the triggered event used for debugging. For example, returned data can include a URI, an SMS provider, or transaction ID.||Object|
While you can create additional user or group fields for an Okta event, the Okta API only supports four fields for Okta connector event cards: ID, Alternate ID, Display Name, and Type. Values will be returned for these four input fields only. No other fields are supported for users or groups, and data from such fields will not be 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.