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)

Output

Field Definition Type
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
Version

Versioning indicator.

String
Actor
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
Target
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 Context
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
Note

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:

API_ACCESS_MANAGEMENT

API_ACCESS_MANAGEMENT_CONSENT

API_ACCESS_MANAGEMENT_EXTENSIBILITY (optional)

If it’s an OIE org, the following feature flag must also be enabled.

ENG_OIE_CONSENT

Related topics

Okta connector

Elements of Workflows

Guidance for Okta connector

Okta API