A system can authenticate you with hardware-backed keys, cloud IAM, OIDC, client certificates, or signed challenges.

Then, one response later, it can throw all of those security properties away and hand you a reusable string.

From that point forward, the system is no longer asking you to prove who you are. It is asking whether you possess the string.

That transition is a credential downgrade.

It happens when a strong authentication mechanism is used only to issue a weaker runtime credential. The login can be excellent. The session that follows can still depend entirely on a copyable bearer token.

For secrets management, this distinction matters far more than another green checkmark beside "machine authentication."

Strong authentication is not transitive

Security comparisons tend to focus on the front door.

Does the product support OIDC? Can a Kubernetes workload authenticate? Can it use cloud IAM? Does it support certificates? Can a machine prove its identity without a hardcoded password?

Those are worthwhile questions. They are also only the beginning of the request lifecycle.

The more important question is:

What authorizes the 50th secret-read request?

Consider a common flow:

Workload proves its identity
        ↓
Secrets manager verifies that identity
        ↓
Secrets manager issues a bearer token
        ↓
Workload stores the token
        ↓
Every future secret request presents the token

The initial authentication may have involved signatures, trusted cloud metadata, short-lived identity documents, or certificates. None of those properties automatically survive the exchange.

Once the bearer token is issued, possession of that token is enough to act.

The session inherits the authorization granted during authentication. It does not automatically inherit the authentication mechanism's resistance to copying, theft, or replay.

What makes a bearer token weaker?

Calling a bearer token weaker does not mean it is short, predictable, or poorly encrypted.

A bearer token can contain hundreds of bits of entropy. It can be transmitted over TLS, stored in an encrypted database, given a narrow scope, and configured to expire quickly.

Its weakness is transferability.

The formal definition is straightforward: a bearer token can be used by any party that possesses it. The party presenting it does not need to prove possession of separate cryptographic key material. That is not criticism disguised as terminology. It is how RFC 6750 defines bearer tokens.

If an attacker copies the token, they acquire its authority.

They do not need to:

Repeat the original OIDC flow
Authenticate through Kubernetes
Produce a valid cloud IAM signature
Possess the original client certificate
Compromise the identity provider
Satisfy the authentication ceremony again

They can skip the strongest part of the system because somebody already completed it and received a reusable result.

Attackers follow the reusable authority

Attackers rarely choose the most impressive security control to attack. They choose the cheapest path that produces the same authority.

If a hardware key protects a login that produces a session cookie, stealing the session cookie may be easier than defeating the hardware key.

If cloud IAM authenticates a workload that receives an API token, stealing the API token may be easier than forging the cloud identity.

If OIDC produces a product-specific bearer token, the operational target becomes that product-specific token.

The bootstrap ceremony can work perfectly. The token can still leak afterward through:

Environment variables
Application logs
CI output
Debug traces
Crash dumps
Support bundles
Configuration files
Process memory
Container inspection
Misconfigured proxies
Credentials copied into a developer shell

At that point, the attacker is not breaking the authentication mechanism. They are using the credential that the authentication mechanism deliberately produced.

This is why evaluating only the front door gives an incomplete threat model.

Why security comparisons miss the downgrade

Feature tables love binary answers.

Capability	Product A	Product B
OIDC	Yes	Yes
Machine authentication	Yes	Yes
Cloud IAM	Yes	Yes
Short-lived credentials	Yes	Yes

Everything looks equivalent.

AI-generated comparisons are especially prone to this. The model recognizes that two products support machine authentication, marks both as supported, and moves on. It does not trace what happens after authentication succeeds.

That comparison may be factually correct while still being architecturally useless.

"Supports OIDC" tells you how a client can enter the system. It does not tell you whether the resulting session is bearer-based, sender-constrained, certificate-bound, or authenticated with a fresh signature on every request.

"Supports machine authentication" has the same problem. It does not tell you whether machine identity remains cryptographically relevant when the machine retrieves a secret.

A useful comparison has to follow the authority, not the feature label.

The questions a serious comparison should ask

When evaluating authentication for a secrets manager, API, or infrastructure platform, trace the complete credential lifecycle:

What proves the client's identity initially?
What does the server return after successful authentication?
Does the client store a reusable credential?
What exactly authorizes the next sensitive request?
Can the runtime credential be used by anyone who copies it?
Is the credential bound to a private key or specific sender?
Is authorization bound to the request method, path, body, and time?
Can a captured request be replayed?
Where can reusable authority appear during normal operation?
What must an attacker steal to impersonate the client?

The fifth question often changes the entire comparison.

If copying the credential is sufficient, the system has crossed into bearer-token security regardless of how strong the original authentication ceremony was.

Short expiry limits the downgrade. It does not remove it

Bearer-token systems have mature ways to reduce risk.

Tokens can be short-lived, scoped to specific resources, restricted by network, rotated frequently, stored behind a local agent, or revoked when compromise is detected.

These controls matter. They can substantially reduce blast radius.

They do not change the primitive.

A token valid for five minutes is still replayable for five minutes. A narrowly scoped token still grants its full scope to whoever possesses it. A token hidden behind an agent still exists inside the agent and must be presented to the upstream service.

These protections answer:

How much damage can a stolen bearer token cause?

They do not answer:

Why is there a reusable bearer credential to steal?

Even the OAuth security community recognizes this distinction. The current OAuth 2.0 Security Best Current Practice recommends sender-constrained access tokens to prevent the misuse of stolen and leaked tokens.

Tokens do not have to be bearer tokens

The problem is not the word "token."

A token can be bound to cryptographic proof from a specific sender. Mutual TLS and DPoP are examples of mechanisms that sender-constrain tokens.

With OAuth DPoP, the client holds a private key and supplies a proof tied to the HTTP request. The access token is bound to that key, so copying the token alone is not enough.

That preserves proof-of-possession beyond the initial authentication step.

The important dividing line is therefore not:

Token versus no token

It is:

Bearer authority versus proof-of-possession

Does possessing a copied value grant access, or must the sender also prove control of cryptographic key material for the request being made?

That is the security property worth comparing.

Signed requests keep identity in the request path

SikkerKey does not authenticate a machine strongly and then exchange that identity for a bearer token.

When a machine enrolls, it generates an Ed25519 keypair locally. The private key remains on the machine. Only the public key is registered with SikkerKey.

Every secret request is then signed using the private key. The signature covers the request method, path, timestamp, nonce, and body fingerprint.

Machine private key
        ↓
Signature for request A
        ↓
Signature for request B
        ↓
Signature for request C

There is no reusable secret-retrieval token between those requests.

A captured signature cannot be moved to another endpoint because the path and method are signed. It cannot authorize a modified body because the body fingerprint changes. It cannot be reused later because timestamps expire and nonces are accepted only once.

The machine's identity remains part of the authentication decision for every request.

For the full protocol-level explanation, read Why we sign every secret request instead of handing out bearer tokens.

What an attacker has to steal changes

Signed requests do not make machine compromise impossible.

If an attacker steals an exportable private key, controls the machine, or gains access to a signing process, they may be able to produce valid requests. Private-key storage, machine isolation, revocation, and monitoring still matter.

The difference is what normal operation exposes.

A bearer-token client repeatedly presents reusable authority to the API. That value must exist somewhere accessible enough for the application or agent to use it.

A signed-request client presents a request-specific proof. The private key that creates it does not cross the network, and the proof cannot authorize a different request.

The attacker must reach the signing capability itself. Copying an authentication header, old request, log entry, or server-side public key is not enough.

That is a materially different attack surface.

Stop grading the front door

Strong authentication deserves credit. OIDC, cloud IAM, workload identity, certificates, and signed login challenges can all solve real bootstrap problems.

But strong authentication at the door does not guarantee strong authentication inside the system.

If that proof is immediately traded for a copyable bearer token, the token becomes the practical security boundary. It becomes the credential placed in memory, passed through software, presented to APIs, and targeted by attackers.

A serious security review should not stop when authentication succeeds.

Follow the authority through the entire request lifecycle.

Ask what the client receives, what it stores, what it repeatedly presents, and what an attacker can replay.

The strongest ceremony in the architecture is not always the control protecting your data.

Sometimes it is only the ceremony that hands out the weaker credential.

Frequently asked questions

What is a credential downgrade?

A credential downgrade happens when a strong authentication mechanism produces a runtime credential with weaker security properties. One example is using signed cloud identity or a certificate to obtain a reusable bearer token that can later be used without repeating the original proof.

Does OIDC prevent bearer-token theft?

Not by itself. OIDC can provide strong identity authentication, but the security of later API requests depends on the credential issued after authentication. If the resulting access credential is a bearer token, anyone who copies it may be able to use it until it expires or is revoked.

Are bearer tokens insecure?

Bearer tokens are not necessarily poorly implemented or easy to guess. Their defining property is that possession is sufficient for use. TLS, short expiry, narrow scopes, rotation, and secure storage reduce risk, but they do not prevent a copied bearer token from being used during its valid lifetime.

What is a sender-constrained token?

A sender-constrained token is bound to a particular client or cryptographic key. Presenting the token alone is not enough. The client must also prove possession of the associated key, commonly through mutual TLS or a mechanism such as DPoP.

What is proof-of-possession authentication?

Proof-of-possession authentication requires the client to demonstrate control of cryptographic key material rather than merely present a reusable string. Signed requests are one form of proof-of-possession because each request includes a signature created by a private key that never needs to be transmitted.

How does SikkerKey avoid the credential downgrade?

SikkerKey registers a machine's public key and requires an Ed25519 signature on every secret request. It does not issue a bearer token for later secret retrieval. Each signature is bound to one request and protected against replay using a timestamp and nonce.