System-issued tokens for service accounts
Issuer Access Tokens (IATs) are machine-identity tokens issued on behalf of service accounts rather than individual users. While a PAT carries your personal identity, an IAT references a service account identity and includes iss (issuer) and aud (audience) claims in the JWT payload, making them suitable for strict machine-to-machine (M2M) authentication flows where the receiving service validates the issuer and audience explicitly.
| Attribute | PAT | IAT |
|---|---|---|
| Issued to | A logged-in user | A service account identity |
| JWT claims | User sub, scopes | Service account sub, iss, aud, scopes |
| Use case | Personal tooling, CI/CD | Machine-to-machine, daemon processes |
| Tied to a person | Yes — revokes if user is disabled | No — independent of any user account |
| Rotation | Revoke + generate new | Rotate (overlap window) or revoke |
Navigate to /idp/token-studio/iats
In Token Studio, click the IATs tab. The list shows all Issuer Access Tokens registered in the system, regardless of which service account they belong to.
| Token Name | Service Account | Issuer | Audience | Scopes | Expiry | Status | Actions |
|---|---|---|---|---|---|---|---|
| payments-service-iat | svc-payments | idp.company.com | payments.api.internal | write | 2026-12-31 | Active |
Rotate
Revoke
|
| audit-reader-iat | svc-audit | idp.company.com | audit.api.internal | read | No expiry | Active |
Rotate
Revoke
|
| Column | Description |
|---|---|
| Token Name | Human-readable name for this IAT definition |
| Service Account | The service account identity this token represents |
| Issuer | The iss claim in the JWT — typically your EmpowerNow IdP URL |
| Audience | The aud claim — the URL or identifier of the target service |
| Scopes | Operations this token is authorised for |
| Expiry | Token expiry date or "No expiry" |
| Status | Active, Expired, or Revoked |
Click "+ Create IAT" and configure the token
Click + Create IAT. Fill in all required fields. The Issuer and Audience values will be embedded as claims in the signed JWT and are validated by the receiving service on every request.
The receiving service must be configured to trust this issuer URL and accept the audience value. Mismatches result in 401 Unauthorized errors. Coordinate with the team owning the target service before creating the IAT.
Generate a new signing key with an overlap window
Click Rotate on an IAT row. Unlike revocation, rotation does not immediately invalidate the existing token. Instead, a new signing key is generated and a configurable overlap window is opened during which both the old and new token values are accepted by the system. This gives downstream systems time to update their stored token value before the old one is retired.
Copy the new token and update downstream systems
After confirming rotation, the new token value is displayed once in a success modal — copy it immediately using the same procedure as for PATs. Then update every system, CI/CD pipeline, and secrets manager entry that references the old token. The old token is automatically revoked at the end of the overlap window.
Before rotating, check which systems are configured with this IAT. An incomplete update will cause service disruptions when the overlap window closes. Maintain an inventory of IAT usage in your infrastructure documentation.
Instantly invalidate an IAT
Click Revoke on an IAT row. Unlike rotation, revocation is immediate with no overlap window. Any downstream system using this IAT will receive a 401 Unauthorized error on its very next request.
Identify and notify the teams responsible for every system using this IAT before revoking. Use revocation only for security incidents where the token may be compromised. For planned replacements, use rotation instead.
Security incident scenarios
| Scenario | Action | Notes |
|---|---|---|
| Token value may be compromised | Revoke immediately | Accept the service disruption — security takes priority |
| Service account is being decommissioned | Revoke all IATs for the service account | Ensure no active systems still depend on the tokens |
| Token approaching expiry | Rotate (not revoke) | Use the overlap window to update downstream systems gracefully |
| Planned key rotation (compliance) | Rotate with overlap | Schedule during a low-traffic window and monitor for errors |