OpenPubkey

OpenPubkey connects OpenID Connect identities to keys that can sign messages and artifacts. It suits teams building identity-backed signing into systems that already trust an identity provider. Its CA-free design is appealing, but today’s provider support and workload requirements constrain its reach.

Overview

OpenPubkey binds an identity to a public key through OpenID Connect. A PK Token shows that an identity controlled its associated private key at a particular time, as long as the verifier trusts the identity provider. That makes OpenPubkey a signing building block rather than a certificate service: it provides no certificate and relies on the identity provider in the certificate authority role.

The project supports user and workload identities, with messages and artifacts as signing targets. Its Go client and verifier example walks through authentication, PK Token creation, signing, and signature verification. Docker is building a public container registry that uses OpenPubkey to sign Docker Official Images, and BastionZero uses it for secure remote infrastructure access.

Key features

Identity-backed signing without a new CA

Teams can tie signing keys to identities from an OpenID Provider without changing that provider or adding another certificate authority. That is a practical fit when the provider already anchors the trust model. Verifiers still need to trust that provider, so this design does not make trust decisions disappear; it places them with the identity provider.

Provider support and replay protection

The project describes compatibility with Google, Azure/Microsoft, Okta, OneLogin, and Keycloak without provider changes. Its client and verifier currently create and verify PK Tokens from Google for users and GitHub for workloads. That gap between stated compatibility and current client support matters: teams relying on another provider should account for the narrower implemented coverage.

For replay protection, GQ signatures let OpenPubkey strip the identity provider’s signature from an ID Token while retaining proof of it. This prevents the token from being used against OIDC resource providers. Workload identity use cases currently require GQ signatures, adding a dependency that does not apply to user scenarios where the PK Token remains private.

Privacy and key handling

A public PK Token can expose claims from the signer’s ID Token, including a name or email address. Teams publishing tokens should consider whether that identity information belongs in public artifacts. OpenPubkey also assumes identity-held key pairs are temporary: users generate them when needed and delete them afterward, so it fits workflows that can manage that lifecycle.

User identity scenarios can add an optional MFA cosigner protocol that independently authenticates the user and cosigns the PK Token. This offers an extra authentication step for users, but it is unsupported for workload identities.

Pricing

OpenPubkey is free. The OpenPubkey plan costs nothing and includes open-source software under the Apache 2.0 license and a reference implementation. That makes it accessible for teams able to operate and integrate the project themselves; no paid tier or hosted service is part of this offering.

The project is a Linux Foundation project and its repository says it is being prepared for version 1.0. Support is directed through GitHub issues for feature requests, bug reports, and technical questions, with a community Slack channel also available. Its security policy asks reporters to email [email protected] privately and says there is no bug bounty program.

Platforms

OpenPubkey supports API, Linux, macOS, self-hosted, and Windows environments. That range suits teams integrating signing into their own software or infrastructure, while its reference implementation and Go example point toward a developer-led setup.

Who it's for

OpenPubkey is strongest for teams that already use an OpenID Provider and want signatures tied to user or workload identity without setting up a separate certificate authority. It is especially relevant to teams signing messages, artifacts, or container images and able to work within its current Google user and GitHub workload support.

It is a weaker fit when public tokens must not reveal identity claims, when workload signing cannot use GQ signatures, or when a team needs a certificate rather than an identity-backed signing token. Teams depending on Azure/Microsoft, Okta, OneLogin, or Keycloak should also check that current client and verifier support meets their needs.

Pros and cons

• Pros: Binds identity to key control through an existing OpenID Provider, avoiding a separate certificate authority.
• Pros: Supports user and workload identity signing for messages and artifacts, with a Go client and verifier flow.
• Pros: Apache 2.0 licensing and a free reference implementation make it available for self-hosted use.
• Cons: Current PK Token creation and verification support is narrower than the project’s compatibility claims: Google for users and GitHub for workloads.
• Cons: Public PK Tokens may reveal a signer’s name or email, and temporary key pairs need deliberate lifecycle handling.
• Cons: All current workload identity use cases require GQ signatures; the optional MFA cosigner does not support workloads.
• Cons: The project is still preparing for version 1.0, and it provides no certificate.

Alternatives

Choose AWS Signer if you need a paid signing option with a free plan and no additional charge for use with the named AWS services or third-party container services. For an open-source signing CLI with no hosted service or usage limits stated, consider Cosign. SignPath offers free open-source code signing subject to eligibility conditions; SignServer has a free community plan for basic code, document, and container signing and timestamping.

Notation is an Apache 2.0 licensed CLI project. Sigstore is free to use for developers and software providers. Eligible, actively maintained open-source projects with an OSI-approved license and manual release signing can consider SignPath Foundation. Aujas Automated Code Signing Platform offers signing-based licenses.

Browse the code signing software directory to compare more options.

Verdict

Choose OpenPubkey if you want to bind signing keys to identities from an existing OpenID Provider and can work with its current Google user and GitHub workload support. Its strongest reason to choose it is identity-backed signing without an added certificate authority. Look elsewhere if your workload flow cannot accommodate GQ signatures, public tokens risk exposing identity claims, or you need a certificate rather than a PK Token.