Category: FIDO & Passkeys

Public Key Cryptography

Also known as: PKC, Asymmetric Cryptography, Public Key Encryption

Simply put

Public key cryptography is a method of securing information that uses a pair of mathematically related keys: a private key kept secret by its owner and a public key that can be shared freely with anyone. Data protected with one key of the pair can be processed with the other, which allows people to exchange information securely or verify who sent something without first sharing a secret password. This is different from older approaches that rely on both parties holding the same single secret key.

Formal definition

Public key cryptography, also called asymmetric cryptography, is a class of cryptographic systems built on pairs of mathematically related keys, where a private key is held secret and a corresponding public key is distributed openly. Depending on the algorithm and how it is applied, the key pair typically supports two distinct operations that should not be conflated: encryption/decryption (data encrypted for a recipient using their public key can be decrypted only with the corresponding private key) and digital signing/verification (data signed with a private key can be verified with the corresponding public key, supporting integrity and origin authentication). In IAM contexts, note that signing provides authentication and integrity but is not the same as encrypting for confidentiality; the specific security properties depend on the algorithm, key sizes, and protocol profile in use. This entry covers the general model; specific schemes, key-exchange mechanisms, and PKI trust management are out of scope here.

Why it matters

Public key cryptography underpins nearly every modern identity and access management protocol. Because it lets two parties establish trust without first sharing a common secret, it enables the secure exchange of information and the verification of a sender's identity at internet scale. This asymmetric model is what allows federation standards, token-based systems, and passwordless authentication mechanisms to function without requiring every relying party to hold a shared secret with every user or issuer.

For IAM practitioners, the distinction between the two operations public key cryptography supports is critical. Digital signing and verification provide integrity and origin authentication, confirming that data was produced by the holder of a particular private key and has not been altered, while encryption and decryption provide confidentiality. These properties are not interchangeable: a signed token is not necessarily an encrypted token, and treating signing as though it protects confidentiality is a common and consequential error. The specific guarantees a system provides depend on the algorithm, key sizes, and protocol profile in use.

The security of the entire model rests on the secrecy of private keys. A public key can be distributed freely to anyone, but if a corresponding private key is exposed, the assurances that depend on it, whether authentication of a signer or confidentiality of encrypted data, collapse. This makes private key protection, storage, and lifecycle handling a central operational concern for any deployment that relies on asymmetric cryptography.

Who it's relevant to

Security Architects

Architects rely on public key cryptography as a foundational building block when designing federation, token issuance, and authentication flows. Understanding that signing provides integrity and origin authentication while encryption provides confidentiality, and that these are separate operations, is essential to selecting the right mechanism for a given security requirement rather than assuming one operation delivers both.

IAM Engineers

Engineers implementing token-based and passwordless systems work directly with key pairs, using private keys to sign and public keys to verify. They must correctly distinguish signing from encryption in practice and ensure that private keys are protected, since the assurances of the whole system depend on private key secrecy.

Compliance Officers

Compliance and audit leads need to understand what security properties public key cryptography actually provides in a given deployment. Because the guarantees depend on algorithm, key sizes, and protocol profile, and because a signed artifact is not necessarily confidential, accurately characterizing controls requires distinguishing authentication and integrity claims from confidentiality claims.

System Administrators

Administrators are often responsible for the operational handling of keys, including distribution of public keys and protection of private keys. Since exposure of a private key undermines the security assurances that rely on it, disciplined key storage and lifecycle handling are a core part of the role.

Inside PKC

Key Pair (Public and Private Keys)

Public key cryptography relies on a mathematically related pair of keys: a private key that is kept secret by its holder and a public key that can be freely distributed. Data operations performed with one key are verified or reversed with the other, but the private key cannot feasibly be derived from the public key.

Digital Signatures

A signature is produced using the signer's private key and verified by anyone holding the corresponding public key. Signatures provide integrity and authenticity assurances; in IAM contexts they underpin signed tokens such as JWTs. Note that a signed token proves integrity and origin but is not the same as an encrypted token, which protects confidentiality.

Encryption and Decryption

A public key can be used to encrypt data that only the corresponding private key holder can decrypt, supporting confidentiality. This is distinct from signing, and the two operations should not be conflated when describing token or message protection.

Certificates and Public Key Infrastructure (PKI)

Certificates bind a public key to an identity and are typically issued and vouched for by a certificate authority within a PKI. This trust chain allows relying parties to validate that a public key belongs to the claimed subject, depending on the trust configuration in place.

Relationship to IAM Protocols

Public key cryptography provides the underlying mechanisms used by federation and token standards. For example, signed assertions in SAML 2.0 and signed tokens issued via OpenID Connect (built on OAuth 2.0) commonly rely on asymmetric signatures for verification by relying parties.

Common questions

Answers to the questions practitioners most commonly ask about PKC.

Does a signed token mean the token is also encrypted and its contents are hidden?

No. Signing and encryption are distinct operations in public key cryptography. A signature (for example over a JWT to produce a JWS) provides integrity and authenticity, letting a relying party verify the token was issued by the holder of the private key and not altered. It does not conceal the contents. A signed-only JWT has a base64url-encoded payload that anyone can decode and read. To protect confidentiality of claims, the token must be encrypted (for example as a JWE), which is a separate step. In most deployments tokens are signed but not encrypted, so sensitive data should not be placed in claims under the assumption that signing hides it.

Does using public key cryptography by itself authenticate a user?

Not on its own. Public key cryptography provides the mechanism, proving possession of a private key corresponding to a known public key, but authentication as an access-flow step also depends on binding that key pair to an identity and on the surrounding protocol. Identification (asserting who the principal is), authentication (verifying it), and authorization (determining what they may do) remain distinct steps. A key pair proves control of a private key; whether that constitutes user authentication depends on how the public key was registered and trusted, and on the protocol profile in use. The cryptography is a building block, not a complete authentication decision.

When issuing signed tokens, how should signing keys be rotated without breaking verification?

Verifiers typically discover current signing keys through a published key set (for example a JWKS endpoint referenced in OIDC discovery metadata), with each key identified by a key ID (kid) carried in the token header. To rotate, the issuer usually publishes the new public key alongside the old one and begins signing new tokens with the new key while the old key remains available until previously issued tokens expire. Verifiers should select the key by kid rather than assuming a single static key. Exact endpoints, caching behavior, and rotation cadence vary by vendor and deployment configuration.

How do relying parties obtain and trust the public keys used to verify tokens?

In many OIDC and OAuth 2.0 deployments, relying parties fetch public keys from a JWKS endpoint advertised in the provider's metadata, matching keys by kid. Trust is generally established because the metadata endpoint is served over TLS from the expected issuer and the issuer value is validated. In PKI-based contexts, trust may instead derive from an X.509 certificate chain anchored to a trusted certificate authority. The appropriate mechanism depends on the protocol profile and how key distribution is configured in your environment.

What are the practical trade-offs of choosing an asymmetric signing algorithm for tokens?

Asymmetric signing (for example RSA or elliptic-curve families) lets the issuer hold the private key while many verifiers use only the public key, which is often preferred in federated setups because verifiers never need a shared secret. Symmetric signing (HMAC-based) requires the verifier to share the secret with the issuer, which can be simpler for a single trust boundary but harder to distribute safely across parties. Algorithm choice also affects key size, signature size, and computational cost, and specific algorithm support depends on the library, standard profile, and vendor.

What operational safeguards apply to protecting private keys used for signing?

Because a compromised signing private key can allow an attacker to forge valid-looking tokens, private keys are typically stored in protected locations such as hardware security modules or managed key services with restricted access, and are subject to rotation and revocation procedures. Access should be limited and audited, and a rotation plan should be in place so a suspected compromise can be remediated by retiring the key and publishing a replacement. The specific controls available depend on the platform and deployment configuration.

Common misconceptions

A signed token is also encrypted and therefore confidential.

Signing and encryption are separate operations. A signature provides integrity and authenticity but does not hide the contents; a self-contained token such as a JWT is typically readable unless it is additionally encrypted. Confidentiality requires an explicit encryption step.

Public key cryptography by itself authenticates a user.

The cryptography proves control of a private key or the validity of a signature. Authentication of a principal depends on how that proof is used within an authentication flow and on correctly binding the key to an identity; possession of a key is a possession-factor input, not a complete authentication decision. Authorization is a separate concern still.

A public key can be trusted simply because it is presented and verifies a signature.

Verifying a signature only confirms it was produced by the matching private key. Establishing that the public key genuinely belongs to the claimed identity typically requires a trust mechanism such as a certificate chain or a configured, pinned key, depending on deployment.

Best practices

Protect private keys with strong storage controls, and where the deployment supports it, keep them in hardware-backed key stores so the key material is not exposed to application processes.

Distinguish signing keys from encryption keys and use each for its intended purpose rather than reusing a single key pair across both operations.

Validate the full trust path when relying on a public key, confirming certificate chains or configured trusted keys rather than trusting any key that merely produces a valid signature.

When protecting tokens, decide explicitly whether integrity, confidentiality, or both are required, and apply signing and encryption accordingly rather than assuming a signed token is confidential.

Establish key rotation and revocation procedures appropriate to your PKI or token-issuing infrastructure, and ensure relying parties can obtain updated public keys.

Confirm how public keys are bound to identities in your federation setup (for example SAML 2.0 or OpenID Connect) so signature verification maps to the correct trusted issuer under your configuration.