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

Related topics

Okta connector

Workflow elements

Guidance for Okta connector

Okta API documentation