Long Running (Asynchronous) Workflows with Trimble ID
Trimble Identity (TID) supports asynchronous workflows where one application acts on behalf of another identity. A typical flow is: a request to one application triggers one or more downstream requests to other applications in a chain. Each application in the chain usually needs a new access token to call the next application until the workflow completes. This chain of applications is called a workflow in this document.
During a workflow, the whole chain runs in a specific subject’s context. Some workflows are one-time (per subject); others are repetitive (for example, a scheduled task). Repetitive workflows can cause the set of active users or subjects to grow over time for the applications involved.
TID classifies workflows by duration and repetitiveness and provides a different mechanism for each class.
Workflow classes
| Class | Duration | Repetitive | Mechanism |
|---|---|---|---|
| Class #1 | < 1 hour | No | Token Exchange (on-behalf) Grant — the initial access token stays valid for the whole workflow. |
| Class #2 | > 1 hour | No | Refresh tokens for on-behalf-of — applications keep a token store and get new access tokens when the first one expires. |
| Class #3 | > 1 hour | Yes | Subject delegation — applications can get on-behalf-of tokens when the primary identity is not present. Requires a support request and TID governing committee review. |
Class #1: Short, one-time workflows
Workflows under one hour that are not repetitive are Class #1.
The whole chain uses the token exchange grant type: the subject is present at the start, and the initial access token is valid for the entire workflow. Downstream applications use that token to obtain new access tokens via token exchange.
See On Behalf Grant / Token Exchange.
Class #2: Long, one-time workflows Long, one-time workflows
Workflows over one hour that are not repetitive are Class #2.
Because these workflows are one-time, the user/subject set stays manageable. Examples: onboarding new users or assignments. The subject is present when the workflow starts, but completion can take time (approvals, acknowledgements). When the workflow is done, on-behalf-of token state for that subject can be cleared.
TID issues refresh tokens for tokens obtained via token exchange. Applications in the chain can maintain a token store and use the refresh token to get a new on-behalf-of access token when the original expires.
Requirements include client authentication via mTLS (certificate from TID) and Demonstrating Proof of Possession (DPoP) for sender-constrained tokens. Refresh tokens have a finite lifetime (for example, 9 days) and cannot be refreshed indefinitely.
See Use refresh tokens for on-behalf-of tokens.
Class #3: Long, repetitive workflows
Workflows over one hour that are repetitive are Class #3.
For repetitive workflows, the active user base can grow over time, so requiring every application in the chain to maintain its own token store is not ideal. TID supports this with the subject delegation grant type: applications in the workflow can obtain on-behalf-of tokens when the primary identity is not present.
Use of subject delegation requires a support request to TID with details about the workflow, the chain of applications, and why it fits Class #3. The TID governing committee reviews the request and application architecture; the rules for this process are documented externally and ensure sound cloud architecture, secure development, and data access management.
Applications that get this privilege are provisioned specific roles/permissions (and scopes) on the customer account for auditing. Customers can revoke this access when it is no longer needed (currently via support request; a self-service portal is planned).
Two sub-classes within Class #3:
- Class #3.1 — Self-hosted applications: Once approved, the privileged application uses the subject-delegation grant type directly to get on-behalf-of tokens for the subject.
- Class #3.2 — Host environment applications: The application runs in an environment provided by a host application. Both the host and the application submit support requests. After approval, the host uses subject delegation and passes the application’s identifier (
delegated_azp) to obtain tokens on behalf of that application.
See Use subject delegation for long-running repetitive workflows.