Temporal

D Temporal (Cloud and self-hosted Server)

Temporal Cloud workers, the Cloud Ops API, tcld and Terraform authenticate with static API keys (mTLS with your own CA is a Namespace-only alternative); no OIDC path exists. Keys always expire (2-year cap) and are API-rotatable, scoped and GitHub partner-revoked, but show no last use. Self-hosted Server can verify your own JWTs. Into your cloud it is keyless on AWS and GCP.

Docs: docs.temporal.io · Checked 2026-10-20 · source YAML · dispute via PR

Inbound D

How a workload running anywhere authenticates to this product.

Static API key owned by a user or Service Account (Authorization: Bearer), accepted by Namespace gRPC endpoints, the Cloud Ops API, tcld and the Terraform provider. Namespaces can instead use mTLS client certificates chained to a CA you upload; the control plane cannot.

docs.temporal.io checked 2026-10-20
“API keys work with Temporal Cloud operational tools, including the Temporal Cloud CLI extension, tcld, Cloud Ops APIs, and the Terraform provider.”
docs.temporal.io checked 2026-10-20
“API keys serve as an authentication mechanism for executing and managing Workflows via the SDK and Temporal CLI, offering an alternative to mTLS-based authentication.”
docs.temporal.io checked 2026-10-20
“Service Accounts use API Keys as the authentication mechanism to connect to Temporal Cloud.”
docs.temporal.io checked 2026-10-20
“Control Plane access is always securely authenticated via API keys or JWT tokens, regardless of how you choose to connect.”
docs.temporal.io checked 2026-10-20
“An API Key for authentication (owned by that User or Service Account)”
docs.temporal.io checked 2026-10-20
“Temporal Cloud authenticates a client connection by validating the client certificate against one or more CA certificates that are configured for the specified Namespace.”
docs.temporal.io checked 2026-10-20
“The default JWT ClaimMapper implementation can be used as is or as a base for a custom implementation of a similar plugin.”
docs.temporal.io checked 2026-10-20
“KeySourceURIs are the HTTP endpoints that return public keys of token issuers in the JWKS format.”
docs.temporal.io checked 2026-10-20
“A typical approach is for ClaimMapper to interpret custom Claims from a caller's JWT, such as membership in groups, and map them to Temporal roles for the user.”
raw.githubusercontent.com checked 2026-10-20
“// JWT audience for validating tokens”
raw.githubusercontent.com checked 2026-10-20
“// Regular expression to parse permissions claim value. The regex should contain named groups "namespace" and "role", for example”

Graded on Temporal Cloud. No OIDC, GitHub Actions, cloud workload identity or token-exchange path is documented for either plane; the Control Plane's "JWT tokens" are the browser-login sessions of tcld and `temporal cloud login`, not federation. Namespace mTLS trusts a CA bundle you upload (with optional certificate filters on the leaf subject), so a customer PKI issuing short-lived leaves avoids handing Temporal a secret; but it is X.509 rather than OIDC, it does not reach the Cloud Ops API, tcld or Terraform, and a Namespace created with API key auth "cannot later enable mTLS alongside API keys". Even Temporal's own Serverless Workers on Lambda and Cloud Run are configured with TEMPORAL_API_KEY or TLS key material. Self-hosted Temporal Server is different: its default JWT ClaimMapper verifies tokens against JWKS URLs you choose (keySourceURIs) with an optional audience, so any issuer works. It does not lift this grade, unlike the best-deployment rule on `elasticsearch`: Elasticsearch's JWT realm is a product feature available on Elastic's hosted service, while Temporal's is a plugin seam on software you run yourself. It maps roles from a Temporal-specific "permissions" claim that CI and cloud workload tokens do not carry (so in practice a claim-adding IdP or a custom Go build), issuer trust is only the JWKS list, subject checks need custom code, and an unconfigured server has no authentication at all (the default noopAuthorizer allows every request).

Outbound A

How this product reaches into your cloud, repos, or other SaaS.

Workflow History Export, Audit Logs and Serverless Workers reach in by assuming an IAM role you create that trusts Temporal's AWS roles (with an External ID for Lambda and AgentCore), or by impersonating a GCP service account you grant to Temporal's service accounts.

docs.temporal.io checked 2026-10-20
“Temporal Cloud creates multiple intermediary IAM roles for export operations for security purposes.”
docs.temporal.io checked 2026-10-20
“Create a service account in the same project that grants Temporal permission to write to your GCS bucket.”
docs.temporal.io checked 2026-10-20
“You can use this AWS CloudFormation template to create an IAM role with access to a Kinesis stream you have in your account.”
docs.temporal.io checked 2026-10-20
“In the service account email field, enter the email of the service account you created in the prerequisites.”
docs.temporal.io checked 2026-10-20
“The trust policy on the role includes an External ID condition to prevent”
docs.temporal.io checked 2026-10-20
“Temporal Cloud scales the Worker Pool by impersonating a service account you create, called the invoker service account.”
docs.temporal.io checked 2026-10-20
“On AWS infrastructure (EC2, ECS, EKS): The server uses the attached instance role, task role, or pod role automatically.”
docs.temporal.io checked 2026-10-20
“Outside AWS: Use IAM Roles Anywhere, or configure static AWS”
docs.temporal.io checked 2026-10-20
“Create the invoker service account that the Temporal Service impersonates to scale the Worker Pool.”
raw.githubusercontent.com checked 2026-10-20
“`credentialsPath` is required but could be empty "" in order to allow a Google default credentials.”
raw.githubusercontent.com checked 2026-10-20
“See https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/configuring-sdk.html#specifying-credentials on how to set up authentication against s3”

Checked on Temporal Cloud: Workflow History Export (S3, GCS), Audit Logs (Kinesis, Pub/Sub), Serverless Workers (AWS Lambda, Cloud Run, Bedrock AgentCore) and private connectivity (PrivateLink, Private Service Connect; endpoints you create, no credential). Temporal Cloud runs on AWS and GCP only, and every reach-in on both is keyless: AWS via a role you create whose trust policy names Temporal's IAM roles (External ID on the Lambda and AgentCore invocation roles; the export and audit-log CloudFormation templates were not inspected for one), GCP via roles/iam.serviceAccountTokenCreator granted to Temporal's service accounts. Metrics flow the other way: your scraper pulls from metrics.temporal.io with a Temporal API key (an inbound credential, covered above). Self-hosted Server: S3 and GCS archival and Serverless Workers use the server's ambient identity (AWS SDK default chain incl. instance, task or pod role or IAM Roles Anywhere; Google default credentials). The docs' GCS archival example points credentialsPath at a keyfile JSON and static AWS keys remain possible but "not recommended"; neither is required.

Hygiene for any static credential the product still issues

✓ Expiry enforceable	Every key carries an expiration date and the platform caps it at two years, so a never-expiring key cannot exist. No org policy to set a shorter cap is documented, and the Namespace page's "Generate API Key" button mints a Namespace-admin key at the full two years. docs.temporal.io checked 2026-10-20 “A: The maximum expiration time for an API key is 2 years.” docs.temporal.io checked 2026-10-20 “Temporal API keys automatically expire based on the specified expiration time.”
✓ Rotation via API	The Cloud Ops API has CreateApiKey, GetApiKeys and DeleteApiKey (plus disable via update); Service Accounts can mint their own replacement key. docs.temporal.io checked 2026-10-20 “Rotate service account keys on a schedule with a job.” docs.temporal.io checked 2026-10-20 “To use this feature, have your Service Account create a new API key using the Cloud Ops APIs or the CLI before the current one expires.”
✓ Scoped keys	A key inherits its owner's permissions, but Service Accounts are purpose-built machine principals with their own account role and per-Namespace permissions (custom roles also exist), which the rubric counts. Keys on user identities inherit that human's access. docs.temporal.io checked 2026-10-20 “Service Accounts afford Temporal Cloud Account Owner and Global Admin roles the ability to create an identity for machine authentication, an identity not associated with a human user.” docs.temporal.io checked 2026-10-20 “Namespace Admins can now manage and create Namespace-scoped Service Accounts, regardless of their Account Role.”
✗ Last-used visible	The ApiKey resource has created_time and last_modified_time but no last-used field, and the API keys page offers filtering by state and identity type only. The docs advise checking "usage metrics and logs" instead. docs.temporal.io checked 2026-10-20 “To find an API key, you can filter by API key state and identity type (Global Administrators and Account Owners only).” raw.githubusercontent.com checked 2026-10-20 “// The date and time when the API key was last modified.”
✓ Leak revocation	The first ✓ is GitHub's Partner column: a Temporal Cloud API key pushed to a public repo is reported to Temporal. docs.github.com checked 2026-10-20 “\| Temporal \| Temporal Cloud API Key \| temporal_cloud_api_key \| ✓ \| ✓ \| ✓ \| ✗ \| ✗ \| ✗ \|”

Notes

One card for Temporal Cloud and self-hosted Temporal Server, which share the same Namespace gRPC API but authenticate it differently; hygiene applies to Temporal Cloud API keys (the self-hosted server issues no credentials). Four of five hygiene checks pass; a last-used timestamp would make it five. Inbound moves to B or A only if Temporal Cloud accepts a federated token (GitHub Actions OIDC, cloud workload identity, or a bring-your-own issuer).

Badge

[![wif.tax grade](https://wif.tax/badge/temporal.svg)](https://wif.tax/p/temporal/)