Before
An administrator or operator would manually assemble the target user's email, requested scope, token claims, and validity period, then generate and exchange a signed token. The resulting token would need to be copied back into the workflow that required user-level access.
How it works
- Receive the target user and requested scope from a principal workflow through a webhook.
- Build time-bound impersonation claims, sign them, and exchange the signed assertion for a bearer token.
- Return the token to the originating workflow for its next user-authorized action.
Workflow details
- Webhook intake: The flow receives a request from a principal workflow containing the target user's email address and the scope required for the intended action.
- Claim preparation: It calculates issue and expiration times, combines the service account identity, requested scope, target user, and token audience into an impersonation claim set, and prepares it for signing.
- JWT generation: The claim set is signed through the configured service account so it can be exchanged for an access token on behalf of the specified user.
- Token exchange: The signed JWT is submitted to the authorization service with the required grant type, producing an impersonated bearer token when the request succeeds.
- Workflow handoff: The resulting access token is returned in the webhook response to the principal workflow, where it can be used for subsequent user-authorized enrichment or remediation actions.
What changed
Token preparation and exchange now happen automatically for each webhook request, with the target user, scope, and token timing handled inside the flow. The principal workflow receives the bearer token directly instead of depending on a manual token-generation handoff.
Work removed
Manually assembling impersonation claims, calculating token timing, generating the signed JWT, requesting the bearer token, and copying the token back to the originating workflow.
Expected outcome
Each invocation can remove at least two manual token-generation actions—the signed assertion creation and token exchange—while consistently returning the resulting bearer token to the requesting workflow.
