The Google Cloud Service Account OpenID Connect Identity Token Creator Role (roles/iam.serviceAccountOpenIdTokenCreator) is a Google Cloud IAM role that allows a principal to create OpenID Connect identity tokens for a service account. Those tokens can be used to prove identity to applications, so the role should be restricted, token creation monitored and service account trust relationships reviewed to avoid impersonation or overbroad delegation.
What this role does in Google Cloud
This role grants the ability to mint OpenID Connect identity tokens for a service account, which means it can create short-lived assertions that other systems may trust as proof of identity. In practice, that makes the role a delegation control, not just an administrative convenience.
Because the resulting token can be presented to applications, the security question is not only who can call the role, but also which service account is being impersonated and which relying parties will accept that token. A role like this sits at the boundary between IAM policy and application trust.
Why token creation is sensitive
OpenID Connect identity tokens are designed to let one system assert identity to another. If the role is overbroad, a principal can generate tokens that appear legitimate to downstream services, which can turn a narrow permission into a cross-application impersonation path. NHIMG’s OAuth 2.0 and OpenID Connect Guide for Identity Teams explains the protocol layer behind those identity assertions, including why token handling must be treated as an access-control issue.
The trust impact is larger than token issuance itself. Once a service account token exists, any application or API that accepts it may grant access based on the service account’s authority, so the real blast radius is determined by the permissions attached to that account and the services that trust it.
How organisations assess exposure
Exposure checks should start with IAM policy review, then move to service account inventory and trust-path mapping. The key questions are which principals hold the role, which service accounts they can target, and whether those accounts are tied to production systems, high-value APIs, or privileged automation.
Monitoring should also look for unusual token creation patterns, especially from identities that do not normally perform delegation or from projects where service account usage is supposed to be tightly scoped. NHIMG’s Google Cloud IAM and Service Accounts Guide covers the surrounding role, impersonation, and least-privilege model that determines whether this permission is appropriate at all.
When reviewing exposure, organisations should also validate whether the service account itself is already overprivileged. A token creator role is much more dangerous when paired with broad downstream rights, because the token becomes a reusable proxy for those rights.
Remediation, detection, and trust review
The safest pattern is to keep the permission tightly bounded, use it only where delegated authentication is genuinely needed, and prefer shorter-lived trust paths wherever possible. If the permission cannot be removed immediately, compensate by narrowing who can call it, reducing the authority of the target service account, and validating which applications accept its tokens.
Detection should focus on both control-plane activity and post-issuance usage. Log review should identify who created tokens, when they were created, and whether the resulting tokens were used from unexpected projects, workloads, or networks. NHIMG’s NHI Authentication Guide is useful here because it distinguishes legitimate machine authentication patterns from insecure delegation and token abuse.
If misuse is suspected, treat the issue as a trust relationship review, not just a permission cleanup. Rotate or revoke adjacent credentials where the token may have enabled lateral access, and re-check any applications that cached, exchanged, or forwarded the token.
Risk and Threat Considerations
This role can become an impersonation primitive when it is granted too broadly, especially in environments where service accounts already have access to APIs, internal platforms, or automation pipelines. Attackers value that path because a valid token often blends in with normal service traffic and can be used without interactive login.
Failure mechanism: A principal with the role can mint identity tokens for a service account, then use those tokens to access systems that trust the account’s asserted identity. If the target account has broad rights or the tokens are accepted by many applications, the compromise can spread from one delegated action into wider internal access.
Impact: The result can be unauthorized application access, privilege abuse, data exposure, and persistence through trusted machine-to-machine flows. In a cloud environment, that can also mask malicious activity because the access appears to come from an approved service identity rather than a human login.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CSA Cloud Controls Matrix and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CSA Cloud Controls Matrix | IAM — Identity & Access Management | This role is an IAM delegation control for service-account token creation. |
| Recommendation — Restrict token-creation rights to approved delegations and review service-account trust paths. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | The role creates identity tokens used by services and workloads to authenticate to other systems. |
| AC-6 — Least Privilege | The role should be limited because it can enable broader delegated access than intended. | |
| Recommendation — Apply IA-9 to constrain service-to-service token issuance and validate relying-party trust. Limit this role to the smallest set of principals and service accounts that truly need it. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The role is an access-control decision about who may create trust-bearing identity tokens. |
| A.5.18 — Access rights | The permission must be reviewed as part of entitlement assignment and periodic access review. | |
| Recommendation — Define and enforce approval rules for who may create service-account identity tokens. Review and recertify this entitlement alongside the target service account’s privileges. | ||
Practitioner Guidance
Governance implication: Treat this permission as a high-sensitivity delegation control and require explicit ownership for every service account that can be tokenized. The main governance mistake is to review the role in isolation, instead of reviewing the role plus the target account plus the relying applications together.
What to watch for: Any principal that can create tokens for production service accounts should be reviewed for necessity, scope, and separation of duties. NHIMG’s IAM and IGA Basics is a good companion for understanding how role assignment, entitlement review, and access governance should shape that decision.
Practitioner takeaway: If the role is needed, make the trust path explicit, narrow the set of callers, and verify that downstream systems only accept the token where the business use case truly requires it.
Related resources from NHI Mgmt Group
- Google Cloud Service Account Token Creator Role (roles/iam.serviceAccountTokenCreator)
- Google Cloud Service Account Creator Role (roles/iam.serviceAccountCreator)
- Google Cloud Service Account Admin Role (roles/iam.serviceAccountAdmin)
- Google Cloud Service Account Key Admin Role (roles/iam.serviceAccountKeyAdmin)