Scope
This guide explores OpenID Connect Key Binding, a proposed Implementer's Draft under review by the OpenID Foundation. We'll discuss what the specification addresses, how it differs from existing token mechanisms, and what your team needs to evaluate before adoption.
We'll focus on OAuth 2.0 and OpenID Connect deployments where you need stronger proof that the party presenting a token is the same party it was issued to. This guide won't cover FIDO2 authentication flows or Verifiable Credentials presentations, which use different binding mechanisms.
Key Concepts and Definitions
Key Binding: This is the cryptographic proof that the client presenting a token possesses a specific private key. The authorization server issues the token bound to a public key, and the client must prove possession of the corresponding private key when using that token.
Sender-Constrained Tokens: These tokens can only be used by the entity that possesses a particular cryptographic key. If an attacker intercepts the token, they can't use it without the private key.
Proof-of-Possession (PoP): A cryptographic demonstration that you control a private key without revealing the key itself. This typically involves signing a challenge or creating a signature over the HTTP request.
Token Replay Attack: An attack where a stolen bearer token is presented by an unauthorized party. Standard OAuth 2.0 bearer tokens don't prevent this; anyone with the token can use it until expiration.
Why Key Binding Matters
OAuth 2.0 bearer tokens work like cash. If you intercept one, you can spend it, creating risk in several scenarios:
- Tokens exfiltrated through compromised TLS sessions
- Tokens leaked in logs or error messages
- Tokens stolen from mobile app storage
- Tokens captured through malicious proxies
Key binding converts bearer tokens into something closer to a credit card: possession alone isn't enough. You need the cryptographic key to use it.
OpenID Connect is used by billions across millions of applications. Any security enhancement to this foundation affects a massive ecosystem. For teams running OpenID Connect as an identity layer over OAuth 2.0, key binding offers a path to stronger token security without overhauling your entire authentication architecture.
Requirements Breakdown
Client Key Generation
Your client application must generate an asymmetric key pair before requesting tokens. The specification will define:
- Acceptable key types (likely RSA, ECDSA, or EdDSA)
- Minimum key lengths
- Key storage requirements
- Key rotation procedures
For mobile apps, use hardware-backed keystores (iOS Secure Enclave, Android Keystore). For server-side clients, evaluate your Hardware Security Module (HSM) integration or cloud key management service.
Token Request Modifications
When requesting an access token, your client proves possession of the private key and provides the public key or a reference to it. The authorization server binds the issued token to that key.
Implementation options typically include:
- Embedding the public key in the token request
- Referencing a pre-registered public key by identifier
- Using a JWT assertion signed with the private key
Token Presentation Requirements
Every resource server request must include proof-of-possession. This usually means:
- Signing the HTTP request (method, URL, headers, body hash)
- Including the signature in a new HTTP header or parameter
- Providing timestamp and nonce to prevent replay
Your resource servers must validate both the token and the signature before granting access.
Implementation Guidance
Start with High-Value Flows
Don't implement key binding everywhere at once. Prioritize:
- Financial transaction APIs where token theft has immediate monetary impact
- Administrative endpoints that modify security configurations
- Data export operations that handle sensitive records in bulk
Client Type Considerations
Confidential clients (server-side applications) can protect private keys in secure storage. Implementation is straightforward.
Public clients (single-page apps, mobile apps) require careful key management. For mobile, use platform keystores. For browser-based apps, evaluate WebCrypto API support and key lifecycle complexity. You might limit key binding to confidential clients initially.
Native apps offer the best security posture for key binding. Hardware-backed keys plus app attestation create strong binding guarantees.
Resource Server Changes
Your APIs need new validation logic:
- Extract and validate the access token (existing flow)
- Extract the proof-of-possession signature
- Retrieve the public key bound to the token
- Verify the signature covers the current request
- Check timestamp freshness and nonce uniqueness
This adds latency. Cache public keys aggressively and optimize signature verification.
Monitoring and Rollback
Instrument both paths:
- Token requests with vs. without key binding
- Signature validation success and failure rates
- Latency impact on protected endpoints
Build the ability to disable key binding validation quickly if you discover an implementation flaw in production.
Common Pitfalls
Clock skew breaks signature validation. If your client and server clocks drift, timestamp-based replay protection fails. Use NTP synchronization and build in acceptable skew windows (typically 60-300 seconds).
Key rotation creates token invalidation. When a client rotates its key pair, existing bound tokens become unusable. Design your rotation procedure to request new tokens before discarding old keys.
Proof-of-possession on every request adds overhead. Each API call requires signature generation and verification. For high-throughput APIs, this matters. Profile the performance impact before deploying to production.
Public key distribution isn't specified uniformly. Different drafts propose different mechanisms for the resource server to obtain the public key (embedded in token, retrieved from authorization server, pre-registered). Understand which approach your implementation uses.
Logging signatures leaks private keys if you're not careful. Never log the signature computation inputs in a way that could expose the private key. Log validation outcomes, not cryptographic intermediates.
Mobile app key backup and restore breaks binding. If users restore an app from backup, the private key might not restore. Plan for key re-registration flows.
Quick Reference Table
| Component | Responsibility | New Requirements |
|---|---|---|
| Client | Key generation, signature creation | Generate asymmetric key pair; sign each request; manage key lifecycle |
| Authorization Server | Token binding, public key storage | Accept public key in token request; bind key to issued token; distribute public key to resource servers |
| Resource Server | Signature validation | Extract PoP signature; retrieve bound public key; validate signature; enforce replay protection |
| Token Format | Carry key binding metadata | Include key identifier or public key; maintain backward compatibility with non-bound tokens |
| Network | Protect keys in transit | TLS remains mandatory; signature doesn't replace transport security |
Next Steps
The OpenID Foundation is voting on this Implementer's Draft. If adopted, you'll see:
- Reference implementations in major OAuth libraries
- Interoperability testing events
- Integration into products from authorization server vendors
Monitor the specification's progression at openid.net. Before production deployment, test interoperability with your authorization server vendor's implementation. Key binding changes both client and server behavior; phased rollout with feature flags is essential.
If you're evaluating this specification, focus on the cryptographic primitives it requires and whether your current client platforms can support them. The security benefit is clear, but implementation complexity varies significantly by client type.
