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)
Scopes
See Event cards for the list of required OAuth scopes needed by this card.
Output
| Field | Definition | Type |
|---|---|---|
|
Date & Time |
Date and time the event was triggered in Okta API. |
Text |
|
Message |
Message details about the event. |
Text |
|
Event ID |
Event's unique identifier key. |
Text |
|
Event Type |
Type of event that was published. |
Text |
|
Event Time |
Time stamp when the notification was delivered to the service. |
Text |
|
Version |
Versioning indicator. |
Text |
|
Actor |
||
|
ID |
Unique identifier of the Okta actor who granted the consent. |
Text |
|
Alternate ID |
Email address of the Okta actor. |
Text |
|
Display Name |
Display name of the Okta actor. |
Text |
|
Type |
Type of Okta actor |
Text |
|
Target |
||
|
ID |
Unique identifier of the scope granted. |
Text |
|
Display Name |
Display name of the scope granted. |
Text |
|
Type |
Type of the scope granted. |
Text |
|
Detail Entry |
Details of the scope granted. |
Text |
|
UUID |
Webhook event's universal unique identifier. |
Text |
|
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. |
Text |
|
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 |
While you can create more 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 this event card doesn't return data from such fields.
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