Identity & Auth · Brennenstuhl on Security

How does authorization work for MCP servers?

Tue, 13 Oct 2026 00:00:00 +0200

Short answer: In the MCP authorization specification (revision 2026-07-28), a protected MCP server over HTTP is an OAuth 2.1 resource server: it publishes Protected Resource Metadata that points clients to its authorization server and accepts only tokens issued for itself. MCP clients discover that authorization server, run the authorization code flow with PKCE, and name the MCP server in a resource parameter on every authorization and token request.

This entry describes the Model Context Protocol (MCP) authorization specification as of revision 2026-07-28, which the MCP versioning page listed as the current revision on 13 October 2026. Later revisions may change these requirements.

Key findings #

As of MCP revision 2026-07-28, MCP servers must implement OAuth 2.0 Protected Resource Metadata (RFC 9728), and MCP clients must use it to discover the authorization server.

Source: Model Context Protocol, Authorization, revision 2026-07-28

Link to this finding Save as image (PNG, 1200 by 630 pixels)

MCP clients must send the RFC 8707 resource parameter with the MCP server’s canonical URI in both authorization and token requests, whether or not the authorization server supports it.

Source: Model Context Protocol, Authorization, revision 2026-07-28

Link to this finding Save as image (PNG, 1200 by 630 pixels)

MCP servers must validate that an access token was issued specifically for them as the intended audience and must not accept or transit any other tokens.

Source: Model Context Protocol, Authorization, revision 2026-07-28

Link to this finding Save as image (PNG, 1200 by 630 pixels)

An MCP server that calls upstream APIs must use a separate token from the upstream authorization server and must not pass through the token it received from the MCP client.

Source: Model Context Protocol, Authorization Security Considerations, revision 2026-07-28

Link to this finding Save as image (PNG, 1200 by 630 pixels)

Evidence #

Primary sources on MCP authorization
Study	Year	Sample	Method	Finding
Model Context Protocol: Authorization (revision 2026-07-28)Model Context Protocol	2026	n/a	Specification	Defines roles, discovery, the authorization flow, the resource parameter, token handling and step-up authorization for HTTP transports.
Model Context Protocol: Authorization Security Considerations (revision 2026-07-28)Model Context Protocol	2026	n/a	Specification	Requires audience binding, PKCE, exact redirect URI matching and a ban on token passthrough.
OAuth 2.0 Protected Resource Metadata (RFC 9728)IETF	2025	n/a	Specification	Defines the metadata document and the WWW-Authenticate parameter that point a client to a resource’s authorization servers.
Resource Indicators for OAuth 2.0 (RFC 8707)IETF	2020	n/a	Specification	Defines the resource parameter and asks authorization servers to audience-restrict tokens to it.
Economies of Scale for MCP and Agentsthis site	2026	n/a	Talk	States that an agent should not hold a shared, long-lived provider credential and presents the broker’s delegation model.

What to do #

For engineers #

For an MCP server over HTTP, publish Protected Resource Metadata, answer unauthenticated requests with a 401 that points to it, and check the audience of every token. Put the scopes an operation needs in the WWW-Authenticate challenge, all at once. If the server calls other APIs, get its own token for each of them. The token exchange entry shows one way to do that.

For an MCP client, implement both discovery mechanisms, PKCE with S256, the resource parameter, and the issuer check. Never put tokens in the query string.

An MCP server on the STDIO transport is outside this specification, which says such servers should take credentials from the environment. Keep those credentials short-lived and task-scoped, as my AppSec essay recommends for coding agents.

For product and UX #

Start with the minimal scopes and ask for more only when an operation needs them. The specification warns that misconfigured scopes may require frequent user interaction, and that challenging one scope at a time forces several authorization round-trips for one operation.

How it works #

The specification defines 3 roles. The MCP server is an OAuth 2.1 resource server, the MCP client is an OAuth 2.1 client acting for a resource owner, and the authorization server issues the tokens. Authorization is optional for MCP implementations. Implementations on HTTP-based transports should conform to the specification, and STDIO implementations should not.

A first connection follows these steps:

The client sends an MCP request without a token. The server answers with HTTP 401 and a WWW-Authenticate header that carries the resource_metadata URL from RFC 9728 and, as the specification recommends, the required scope.
The client fetches the Protected Resource Metadata and picks an authorization server from it. It then reads that server’s metadata through OAuth 2.0 Authorization Server Metadata (RFC 8414) or OpenID Connect Discovery. Clients must support both, and if the metadata doesn’t list code_challenge_methods_supported, the client must refuse to proceed.
The client gets a client ID. It uses pre-registered client information if it has some, then Client ID Metadata Documents if the authorization server supports them. Dynamic Client Registration is deprecated and kept only as a fallback for backwards compatibility.
The client starts the authorization code flow with PKCE, the resource parameter and the selected scopes, and records the expected issuer. When the response comes back, it validates the iss parameter (RFC 9207) before it redeems the code.
The client redeems the code with the code_verifier and the resource parameter, then sends the access token in the Authorization: Bearer header on every request.

When a token lacks a scope at runtime, the server answers with 403 and error="insufficient_scope". The client then runs a step-up flow with the union of its previous scopes and the new ones.

Revision 2026-07-28 doesn’t cover token exchange in its core authorization pages. Optional authorization extensions live in a separate repository. In the Agentic Identity Broker, which Magnus Jungsbluth and I built, an MCP gateway exchanges the agent’s token for the matching provider token through RFC 8693, so the provider token never reaches the agent. I describe that design in the retrospective, and we presented it in our AGNTCon + MCPCon talk.

How should people grant and revoke an agent's access?

Tue, 13 Oct 2026 00:00:00 +0200

Short answer: Let people grant each agent access per service, with a permission set they choose and an expiry, and let them revoke that grant at any time. Revoking the grant has to stop every token derived from it, so keep issued tokens short-lived and check the grant whenever a new token is issued.

Key findings #

In the Agentic Identity Broker, a user grants an agent access to a service with a chosen permission set and an optional expiry, and can revoke that grant at any time.

Source: What I Learned Building an Identity Broker With Coding Agents (janbrennenstuhl.eu, 2026)

Link to this finding Save as image (PNG, 1200 by 630 pixels)

Under RFC 7009, revoking a refresh token should also invalidate all access tokens based on the same authorization grant if the authorization server supports access token revocation.

Source: RFC 7009, OAuth 2.0 Token Revocation (IETF, 2013), Section 2.1

Link to this finding Save as image (PNG, 1200 by 630 pixels)

Immediate revocation of self-contained access tokens needs backend coordination that RFC 7009 calls non-standardized, and short-lived access tokens limit how long a revoked token stays in use.

Source: RFC 7009, OAuth 2.0 Token Revocation (IETF, 2013), Section 3

Link to this finding Save as image (PNG, 1200 by 630 pixels)

Evidence #

Primary sources on agent consent and revocation
Study	Year	Sample	Method	Finding
OAuth 2.0 Token Revocation (RFC 7009)IETF	2013	n/a	Specification	Defines a revocation endpoint and how revoking one token can revoke related tokens and the grant.
Best Current Practice for OAuth 2.0 Security (RFC 9700)IETF	2025	n/a	Specification	Binds refresh tokens to the consented scope and resources and lets them expire after inactivity.
Resource Indicators for OAuth 2.0 (RFC 8707)IETF	2020	n/a	Specification	Lets the authorization server tell the user which resources a client will access on their behalf.
OAuth 2.0 Token Exchange (RFC 8693)IETF	2020	n/a	Specification	Leaves revocation of tokens issued by an exchange to the implementation.
Model Context Protocol: Authorization (revision 2026-07-28)Model Context Protocol	2026	n/a	Specification	Asks clients to request minimal scopes first and add scopes through step-up authorization.
What I Learned Building an Identity Broker With Coding Agentsthis site	2026	n/a	Field report	Describes per-agent grants with chosen permissions, optional expiry and revocation at any time.

What to do #

For engineers #

Model the grant as a record of its own that names the person, the agent, the service, the permissions and the expiry, and issue every token from it. Check that record whenever you issue or exchange a token, so a revocation takes effect at the next tool call. Expiring tokens are the fallback for tokens you can’t recall.

Wire revocation through every layer you control. Call the RFC 7009 revocation endpoint where the provider offers one, and don’t stop at the first token. RFC 8693 says tokens issued by a token exchange aren’t linked to their input token, so revoking one doesn’t reach the other unless you build that.

Ask for the least access first. The MCP authorization specification describes this as step-up authorization: request minimal scopes and add more when a server asks for them.

For product and UX #

Show each grant with the agent, the service, the permissions and the expiry in plain words, and put the revoke action next to it. Default to an expiry instead of open-ended access. When an agent needs more access, ask at that moment for that specific permission.

How it works #

Granting access in OAuth starts with an authorization request. The client names the access it wants in scope and, with RFC 8707, the resources in resource. RFC 8707 notes that the authorization server can use those resource values to inform the user about the resources the client will access on their behalf. The consent screen can then name the service, not only a list of scopes.

In the Agentic Identity Broker, which Magnus Jungsbluth and I built, a user grants an agent access to a service with a chosen permission set and an optional expiry. The broker keeps both the user and the agent in every authorization decision. I describe the design in the retrospective, and my AppSec essay argues for narrow, time-limited permissions that the user can revoke at any moment.

Revoking access in OAuth uses the revocation endpoint from RFC 7009. A client sends the token it wants revoked, and the server invalidates it and, depending on policy, related tokens and the grant itself. RFC 7009 gives 2 reasons this matters for people: it stops a grant from staying valid without the user’s knowledge, and revoked grants disappear from any list of grants the authorization server shows the user. The server answers with HTTP 200 even for an invalid token. A 503 means the client must assume the token still exists.

Self-contained tokens make revocation harder. A resource server can check a self-contained token, such as a JSON Web Token (JWT), without asking the authorization server, so it won’t learn about a revocation on its own. RFC 7009 names short-lived access tokens with refresh tokens as one alternative. RFC 9700 adds that refresh tokens must stay bound to the consented scope and resources, should expire after a period of inactivity, and may be revoked on security events such as a password change or logout.

How does OAuth 2.0 Token Exchange keep provider tokens away from agents?

Tue, 13 Oct 2026 00:00:00 +0200

Short answer: OAuth 2.0 Token Exchange (RFC 8693) lets a client trade one token for another token meant for a specific target service. When a gateway runs that exchange on each tool call, as in the Agentic Identity Broker, the provider token stays between the broker, the gateway and the provider and never reaches the agent.

Key findings #

RFC 8693 lets a client present a security token to an OAuth 2.0 authorization server acting as a Security Token Service and receive a new token, for example one scoped more narrowly for a downstream service.

Source: RFC 8693, OAuth 2.0 Token Exchange (IETF, 2020), Section 1

Link to this finding Save as image (PNG, 1200 by 630 pixels)

In the Agentic Identity Broker, an MCP gateway exchanges the agent’s token for the matching provider token through RFC 8693 on each tool call, so the provider token never reaches the agent.

Source: What I Learned Building an Identity Broker With Coding Agents (janbrennenstuhl.eu, 2026)

Link to this finding Save as image (PNG, 1200 by 630 pixels)

RFC 8693 warns that without client authentication at the token endpoint, anyone holding a compromised token can trade it for other tokens.

Source: RFC 8693, OAuth 2.0 Token Exchange (IETF, 2020), Section 2.1

Link to this finding Save as image (PNG, 1200 by 630 pixels)

In a JWT issued through token exchange, access control decisions must consider only the top-level claims and the current actor named in the act claim, while nested prior actors are informational.

Source: RFC 8693, OAuth 2.0 Token Exchange (IETF, 2020), Section 4.1

Link to this finding Save as image (PNG, 1200 by 630 pixels)

A token exchange creates no tight link between the input and output tokens, so passing revocation from one to the other depends on the implementation and isn’t a property of the protocol.

Source: RFC 8693, OAuth 2.0 Token Exchange (IETF, 2020), Section 2.1

Link to this finding Save as image (PNG, 1200 by 630 pixels)

Evidence #

Primary sources on token exchange for agents
Study	Year	Sample	Method	Finding
OAuth 2.0 Token Exchange (RFC 8693)IETF	2020	n/a	Specification	Defines the token exchange grant, its request and response parameters, and the act and may_act claims.
Resource Indicators for OAuth 2.0 (RFC 8707)IETF	2020	n/a	Specification	Defines the resource parameter that tells the authorization server where a token will be used.
What I Learned Building an Identity Broker With Coding Agentsthis site	2026	n/a	Field report	Describes how a gateway exchanges the agent’s token for the matching provider token on each tool call.
Economies of Scale for MCP and Agentsthis site	2026	n/a	Talk	Presents the broker’s delegation model at AGNTCon + MCPCon Europe 2026.

What to do #

For engineers #

Put the exchange in a component the agent can’t control, such as a gateway, and authenticate that component at the token endpoint. Name the target with resource or audience and ask for the smallest scope the tool call needs. RFC 8693 points out that broad requests across many target services are more likely to be refused.

Treat revocation as your own job. The RFC leaves it to the implementation whether revoking a grant or an input token affects tokens already issued, so keep issued tokens short-lived and check the grant at exchange time. Consent and revocation covers the rest.

If an agent’s token can travel further, use the act claim to record the agent as the actor and the may_act claim to state who may act for the subject.

For product and UX #

Users don’t see the exchange, but they see its effects. When a tool call fails because a grant expired or was revoked, tell the user which service and which agent were affected and how to grant access again.

How it works #

RFC 8693 defines the exchange as 1 request and 1 response at an authorization server’s token endpoint. With a gateway between an agent and its tools, the exchange runs like this:

Step through the exchange

The agent calls a tool through the gateway and presents its own token.
The gateway acts as the RFC 8693 client. It sends a POST to the token endpoint with grant_type=urn:ietf:params:oauth:grant-type:token-exchange, a subject_token that represents the person on whose behalf the request is made, and its subject_token_type. Optional parameters name the target (resource, audience), the access wanted (scope), and the token type wanted (requested_token_type).
The gateway authenticates with the normal OAuth 2.0 client authentication methods.
The authorization server validates the presented tokens and decides by policy whether to issue a token for the named target. If it refuses, it answers with invalid_request, or with invalid_target when it won’t issue a token for the requested target.
A successful response is a normal OAuth token response: access_token carries the issued token, together with issued_token_type, token_type, and, as recommended, expires_in. The issued token doesn’t have to be an OAuth access token.
The gateway calls the target service with the issued token and returns only the result to the agent.

The following request shows step 2 with placeholder hosts and tokens. It illustrates the RFC parameters and isn’t the broker’s API. I’ve left the values unencoded and added line breaks for readability; a real request URL-encodes the form body.

token-exchange.http

POST /token HTTP/1.1
Host: broker.example.com
Authorization: Basic <gateway client credentials>
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&subject_token=<token the agent presented>
&subject_token_type=urn:ietf:params:oauth:token-type:access_token
&resource=https://api.provider.example/
&scope=<permissions the tool call needs>

The Agentic Identity Broker that Magnus Jungsbluth and I built uses this pattern, as I describe in the retrospective. A user grants an agent access to a service, such as GitHub, with a chosen permission set and an optional expiry, and the broker stores the provider tokens encrypted. On each tool call, an MCP gateway such as agentgateway exchanges the agent’s token for the matching provider token, so the provider token never reaches the agent.

RFC 8693 also defines an optional actor_token for the party that will act on behalf of the subject. In the issued JWT, the act claim can record that actor, and nested act claims record a chain of earlier actors. The broker roadmap lists token exchange for agent-to-agent calls as planned work.

What is inside a JWT?

Tue, 13 Oct 2026 00:00:00 +0200

Short answer: A signed JWT is 3 base64url-encoded parts joined by dots: a header that names the algorithm, a payload of claims, and a signature over both. The payload is encoded, not encrypted, so anyone holding the token can read it; only a signature check with a key you trust tells you whether to believe it.

Key findings #

A JWT is a set of claims encoded as a JSON object inside a JWS or a JWE, so the same token format can be signed, encrypted, or both.

Source: RFC 7519, JSON Web Token (JWT), Section 2

Link to this finding Save as image (PNG, 1200 by 630 pixels)

The payload of a signed JWT is only base64url-encoded, so a token that carries privacy-sensitive claims needs encryption or must not reach parties who should not read it.

Source: RFC 7519, Section 12, Privacy Considerations

Link to this finding Save as image (PNG, 1200 by 630 pixels)

RFC 7519 registers 7 claim names, iss, sub, aud, exp, nbf, iat and jti, and none of them is mandatory in every case; each application profile decides which it requires.

Source: RFC 7519, Section 4.1

Link to this finding Save as image (PNG, 1200 by 630 pixels)

JWT libraries must let the caller specify the supported algorithms and must not use any other algorithm, which closes the door on tokens whose header was changed to “none”.

Source: RFC 8725, JSON Web Token Best Current Practices, Section 3.1

Link to this finding Save as image (PNG, 1200 by 630 pixels)

Evidence #

Specifications
Study	Year	Sample	Method	Finding
RFC 7519: JSON Web Token (JWT)IETF	2015	n/a	Specification	Defines the JWT format, the registered claim names and the privacy considerations for claims.
RFC 7515: JSON Web Signature (JWS)IETF	2015	n/a	Specification	Defines the compact serialization: base64url header, payload and signature joined by dots.
RFC 8725: JSON Web Token Best Current PracticesIETF (BCP 225)	2020	n/a	Best current practice	Requires algorithm allowlists in libraries and audience, issuer and key validation in applications.

What to do #

For engineers #

Treat a decoded payload as untrusted input until the signature verifies. Pin the algorithms you accept instead of reading alg from the token, and resolve the key by kid only from a key set you trust, such as the issuer’s JWKS.
After the signature, check exp, nbf, iss and aud. RFC 8725 makes audience validation a must whenever one issuer serves several relying parties.
Keep secrets and personal data out of signed tokens. If a token has to carry them, use JWE or keep the data on the server and put a reference in the token.

For product and UX #

Tokens end up in logs, browser storage and support tickets. Anything in the payload should be safe to show to whoever might see it there.
Short token lifetimes are a product decision as much as a security one: they decide how often a session has to be refreshed.

Try it #

Decode a token in your browser

The example token below has 3 parts. Paste your own token into the decoder to split and decode it. Decoding happens only in your browser; nothing is sent anywhere, and the signature is not verified.

eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IjIwMjYtMTAifQ.eyJpc3MiOiJodHRwczovL2lkLmV4YW1wbGUuY29tIiwic3ViIjoidXNlci0xMjMiLCJhdWQiOiJodHRwczovL2FwaS5leGFtcGxlLmNvbSIsImV4cCI6MTc5MTkwMDAwMCwiaWF0IjoxNzkxODk2NDAwLCJqdGkiOiI3ZjNjOWEifQ.cGxhY2Vob2xkZXIgc2lnbmF0dXJlLCBub3QgdmFsaWQ

Header decodes to {"alg":"ES256","typ":"JWT","kid":"2026-10"}: an ECDSA P-256 signature, and the ID of the key that made it.
Payload decodes to {"iss":"https://id.example.com","sub":"user-123","aud":"https://api.example.com","exp":1791900000,"iat":1791896400,"jti":"7f3c9a"}: issued at 13:00 UTC on 13 October 2026, expiring 1 hour later.
Signature is a placeholder in this example. In a real token it is the ES256 signature over the encoded header and payload, checked with the issuer’s public key from its JWKS.

How the parts fit together #

The header and payload are JSON objects. Each is encoded with base64url, a URL-safe variant of base64 without padding, and the two results are joined with a dot. The signer signs that string with the algorithm named in the header and appends the base64url-encoded signature after a second dot. That is the JWS compact serialization from RFC 7515.

A verifier reverses the steps: split at the dots, decode the header, pick the key and algorithm it allows, and verify the signature over the first 2 parts exactly as received. Only then does it decode the payload and evaluate the claims. The essays on the purpose of JWT, JSON Web Algorithms and JWT versus OAuth 2.0 go deeper.

Should an agent use a robot account or delegated access?

Tue, 13 Oct 2026 00:00:00 +0200

Short answer: When an agent acts for a person, give it delegated access that names both the person and the agent, with narrow scopes, an expiry, and a way to revoke it. A robot account shared by several people gives the agent their combined permissions and hides whose request was whose.

Key findings #

When several people share an agent that holds a robot account, the agent acts with the combined permissions of all its users, and nobody can tell whose request was whose.

Source: What I Learned Building an Identity Broker With Coding Agents (janbrennenstuhl.eu, 2026)

Link to this finding Save as image (PNG, 1200 by 630 pixels)

Under the delegation semantics of OAuth 2.0 Token Exchange, the acting party keeps its own identity, separate from the person whose rights it uses.

Source: RFC 8693, OAuth 2.0 Token Exchange (IETF, 2020), Section 1.1

Link to this finding Save as image (PNG, 1200 by 630 pixels)

The OAuth 2.0 security best current practice says an access token’s privileges should be restricted to the minimum the use case requires, and the token should be audience-restricted to a specific resource server.

Source: RFC 9700, Best Current Practice for OAuth 2.0 Security (IETF, 2025), Section 2.3

Link to this finding Save as image (PNG, 1200 by 630 pixels)

Coding agents should not hold persistent identity and access management (IAM) roles or long-lived API keys; an identity broker can issue short-lived, task-scoped credentials on demand instead.

Source: AppSec in the Age of Agentic Engineering (janbrennenstuhl.eu, 2026)

Link to this finding Save as image (PNG, 1200 by 630 pixels)

Evidence #

Primary sources on robot accounts and delegated agent access
Study	Year	Sample	Method	Finding
OAuth 2.0 Token Exchange (RFC 8693)IETF	2020	n/a	Specification	Defines delegation and impersonation semantics and the act claim that names the acting party.
Best Current Practice for OAuth 2.0 Security (RFC 9700)IETF	2025	n/a	Specification	Asks for least-privilege, audience-restricted tokens and warns when resource servers can’t tell client tokens from user tokens.
Model Context Protocol: Authorization (revision 2026-07-28)Model Context Protocol	2026	n/a	Specification	Treats clients acting for a user differently from clients acting on their own behalf.
What I Learned Building an Identity Broker With Coding Agentsthis site	2026	n/a	Field report	Explains why the Agentic Identity Broker keeps both the user and the agent in every authorization decision.
AppSec in the Age of Agentic Engineeringthis site	2026	n/a	Essay	Argues for short-lived, task-scoped credentials and user-revocable delegation for agents.

What to do #

For engineers #

Ask first whom the agent acts for. If it runs a job on its own behalf, a dedicated client with its own narrow permissions is a reasonable fit. The MCP authorization specification explicitly mentions such client_credentials clients. If it acts for a person, use a grant that names that person and that agent, and keep it narrow and short-lived as RFC 9700 asks.

Prefer delegation over impersonation. A delegated token can carry the agent as the actor next to the person as the subject, so a resource server and your logs can tell them apart. RFC 9700 also warns that a resource server that can’t distinguish tokens obtained with a person’s involvement from tokens a client obtained on its own may let that client reach the person’s resources.

Keep provider credentials out of the agent’s context. Token exchange shows how a gateway can do this on each tool call.

For product and UX #

Show people which agent holds access to which service, with what permissions and until when. Give them one place to revoke that access. If several people use the same agent, show each of them only the grants they made.

How it works #

With a robot account, the agent holds a long-lived credential for each MCP server or API it calls. In OAuth terms, that is closest to a client that gets tokens for itself, without a person in the flow. RFC 9700 quotes the JSON Web Token (JWT) profile for access tokens (RFC 9068): the sub claim of such a token should identify the client application, while a token obtained with a person’s involvement should identify that person. A robot account therefore can’t express who asked for an action. In my retrospective, I describe the consequences once several people share the agent: combined permissions, no attribution, and credentials within reach of anything that tricks the agent.

RFC 8693 describes 2 ways one party can use another’s rights. With impersonation, party A gets B’s rights and is indistinguishable from B in that context. With delegation, A keeps its own identity, and it’s explicitly understood that A acts for B. The RFC uses this exact phrase: “In a sense, A is an agent for B.” A token that carries both identities is a composite token. In a JWT, the act claim names the acting party.

The Agentic Identity Broker that Magnus Jungsbluth and I built applies delegation. A user grants an agent access to a service with a chosen permission set and an optional expiry and can revoke the grant at any time. The broker keeps both the user and the agent in every authorization decision. The essay and our AGNTCon + MCPCon talk explain the design, and the project page links the code.

This model covers agents that act for a person. For autonomous agents with no human in the loop, I wrote in the retrospective that every approach I know of is still brittle.

Economies of Scale for MCP and Agents

Fri, 18 Sep 2026 00:00:00 +0200

Presented by Magnus Jungsbluth and Jan Brennenstuhl at AGNTCon + MCPCon Europe in Amsterdam on 18 September 2026.

Materials #

Reading companion #

An agent should not hold a shared, long-lived provider credential. The broker ties delegated access to both the person and the agent, with chosen permissions and optional expiry. On a tool call, a gateway exchanges the agent’s token for a provider token; the provider token does not enter the agent’s context.

This is a short reading companion, not a transcript. The supporting article explains the identity model and the engineering lessons in accessible HTML.

Agentic Identity Broker

Tue, 15 Sep 2026 00:00:00 +0200

Magnus Jungsbluth and I built the open-source Agentic Identity Broker. It keeps the user and the agent in authorization decisions and stores provider tokens outside the agent’s context.

Explore the project #

The project is licensed under MIT. This page reflects the September 2026 release; consult the project documentation for current capabilities.

Mastering JWKS: JSON Web Key Sets Explained

Fri, 02 Jun 2023 00:00:00 +0200

TL;DR #

JWKS (JSON Web Key Set) is a tool for standardizing the representation and management of cryptographic keys via a JSON object.
The technology, defined in RFC 7517, enables client-local JWT (JSON Web Tokens) verification and is integral for decentralized authentication protocols such as OpenID Connect and OAuth2.
Implementing JWKS simplifies key management, eases key rotation, and secures key distribution across multiple servers.

Technical Specifications of JWK and JWKS #

JWKS is an acronym for JSON Web Key Set. It is a collection of JSON Web Keys (JWKs) used to verify JSON Web Tokens (JWTs). Both constructs are defined in RFC 7517, yet another integral member of the famous JOSE standards family. JWK Sets provide a standardized way and format for servers to obtain the public keys required to verify asymmetrically signed JWTs locally.

What is JSON Web Key (JWK)? #

A JWK is a JSON object data structure that represents a cryptographic key. It contains the key type, key operations, algorithm, and all relevant material to reconstruct the signature verification key. All officially supported JSON Web Algorithms (JWA) are defined in RFC 7518.

The JSON data structure of the JWK format allows for easy, web-native exchange of public keys. The representation of an Elliptic Curve signature key of curve P-256 could look like this:

{
 "kty": "EC",
 "use": "sig",
 "crv": "P-256",
 "kid": "01H1SG7BX197N040C0MHTDV1HR",
 "x": "SEfcECpwqQg-vZ6Lv99RyV0Qkatngz1RV25nI5SOrPg",
 "y": "YU2PRA6pXZ62OW_XuzjJqplqmBUtBwT2pKUZUVxUYfc",
 "alg": "ES256"
}

What is JSON Web Key Set (JWKS)? #

A JWKS is a JSON object that represents a set of JWKs. It must contain a “keys” member and an array of JWKs. JSON Web Key Sets enable identity providers to support and expose more than one public key under a well-known resource. The following example JWK Set format contains two public cryptographic keys – one using an Elliptic Curve (EC) algorithm and a second one using an RSA algorithm:

{"keys":
 [{
 "kty": "EC",
 "use": "sig",
 "crv": "P-256",
 "kid": "01H1SG7BX197N040C0MHTDV1HR",
 "x": "SEfcECpwqQg-vZ6Lv99RyV0Qkatngz1RV25nI5SOrPg",
 "y": "YU2PRA6pXZ62OW_XuzjJqplqmBUtBwT2pKUZUVxUYfc",
 "alg": "ES256"
 }, {
 "kty":"RSA",
 "n": "1qrQCTst3RF04aMC9Ye_kGbsE0sftL4FOtB_WrzBDOFdrfVwLfflQuPX5kJ-0iYv9r2mjD5YIDy8b-iJKwevb69ISeoOrmL3tj6MStJesbbRRLVyFIm_6L7alHhZVyqHQtMKX7IaNndrfebnLReGntuNk76XCFxBBnRaIzAWnzr3WN4UPBt84A0KF74pei17dlqHZJ2HB2CsYbE9Ort8m7Vf6hwxYzFtCvMCnZil0fCtk2OQ73l6egcvYO65DkAJibFsC9xAgZaF-9GYRlSjMPd0SMQ8yU9i3W7beT00Xw6C0FYA9JAYaGaOvbT87l_6ZkAksOMuvIPD_jNVfTCPLQ",
 "e":"AQAB",
 "alg":"RS256",
 "kid":"01H1SGVCX7GKBGE2J2QMQREAGN"
 }]
}

Locate JSON Web Key Sets #

Many modern identity providers like Google expose their JWK Sets via the jwks_uri attribute within the well-known discovery endpoint of OpenID Connect (OIDC) located at https://{identity-provider}/.well-known/openid-configuration which often points to https://{identity-provider}/.well-known/jwks.json or a similar resource.

Benefits of Using JWKS #

Easy Management of Keys with JWK Sets #

One of the main benefits of using JWKs is that they provide an easy way to manage and distribute keys across multiple servers or locations. Instead of hardcoding public keys into application code, token issuers (authorization servers) only need to provide their clients with an URL for their JSON Web Key Set.

Any application that needs access to the keys can retrieve them from that remote location. This eliminates the need for manual key distribution, resolves, and ensures all applications use the same set of keys. This makes it easier to manage multiple keys and rotate them when necessary.

Simplified Key Rotation Process Using JWKs #

Rotating keys is essential for maintaining security in any system that uses cryptography. However, manually replacing these keys can take time and effort. JWKS can simplify this process by automating key rotation.

As JWKs decouple the authorization server from relying party applications, token issuers can generate new asymmetric key pairs whenever necessary. Setting up regular intervals for key rotation, publishing the new public key material, and using the latest private key automatically after some grace period, can ensure that the amount of keys signed with a particular key has a natural upper limit.

Compatibility with Various Protocols and Applications #

Finally, the JSON Web Key Set standard is compatible with various protocols and applications. This means it can enable local token validation in the context of web applications, APIs, mobile apps, and more. Popular authentication protocols such as OAuth 2.0 and OpenID Connect support JSON Web Key Set.

Best Practices & Security Considerations #

Dealing with cryptographic and primarily private keys is a highly sensitive undertaking. The security issues relevant to any cryptographic application must also be considered when dealing with JSON Web Token (JWT) and JSON Web Signature (JWS). It is essential to implement JSON Web Key Set (JWKS) correctly to ensure the security and integrity of the entire infrastructure. Here are some best practices for implementing JWKS.

Use Transport Layer Security #

Serving a JSON Web Key over HTTP poses significant security risks as it can be intercepted or modified in transit. Therefore, it is crucial to use HTTPS also when serving JWKS. HTTPS ensures that all communication between the client and server is encrypted, preventing unauthorized access or in-transit modification.

Make sure JWKS is correct and current #

The entire system’s security relies on having up-to-date and accurate JWKS. If any cryptographic keys in the set expire or become invalid, it could result in rejected tokens or, worse yet, accepted but fraudulent tokens being used throughout the system. It’s essential to have processes in place to monitor and update JSON Web Keys regularly. This includes rotating keys, removing EOL keys, and adding new keys as necessary. Cryptographic key management should be automated to ensure that all cryptographic keys are always up-to-date. Symmetric keys must not be exposed!

Validate the signatures of incoming JWTs using JWKs #

One of the primary purposes of implementing JWKS is to verify the authenticity of incoming JWTs – be it access token or ID token. To do this, all applications that perform authorization decisions based on JSON Web Token, should fetch the entire JSON Web Key Set per the corresponding cache-control headers.

Validating a JWT starts with fetching the kid (key ID) parameter from its header. This key identifier specifies which cryptographic key in the JWKS was used by the authorization server to sign the token. The identified key can then be used to verify the signature by comparing it against the one included in the token’s signature.

If the signature is valid, the token was issued by a trusted party and can be processed accordingly. An invalid token must be rejected immediately.

Consider rotating your JWKS keys periodically #

Rotating JSON Web Keys periodically is an essential best practice for maintaining a proper security posture. Doing so reduces the risk of compromised keys being used maliciously throughout the system. Rotating keys effectively requires creating a new set before retiring any old ones. This will ensure no gaps in coverage during the transition period.

Conclusion: The Importance of Using JSON Web Key Sets #

Implementing JSON Web Key Sets (JWKS) is crucial for organizations that leverage decentralized authentication protocols like OpenID Connect or authorization delegation protocols like plain OAuth2. Truly benefiting from public-key cryptography requires client applications to verify issued tokens locally, without indispensable synchronous HTTP requests.

Using a data interchange format like JSON Web Key (JWK), which is based on JavaScript Object Notation (JSON), and hosting the cryptographic keys on publicly accessible, standardized discovery endpoints allows maintaining decoupled service architectures while shifting effort to the client-side following a pull principle.

JSON Web Encryption: Exploring JWE Token

Mon, 29 May 2023 00:00:00 +0200

TL;DR #

JSON Web Encryption (JWE) is a standard for securing data transmission between parties, providing confidentiality, integrity, and authentication. It uses encryption to protect the payload of a JSON Web Token (JWT) and supports both symmetric and asymmetric encryption techniques. It also allows creating nested JWTs, combining the advantages of JWE and JSON Web Signature (JWS).
A JWE token consists of five parts: the Protected Header, the Content Encryption Key, the Initialization Vector, the Ciphertext, and the Authentication Tag. It supports various encryption algorithms like RSA-OAEP, AES-GCM, and ECDH-ES and requires using authenticated encryption to ensure the token’s integrity and confidentiality.
Modern authentication and authorization frameworks like OAuth2 and OpenID Connect (OIDC) use JWE tokens as bearer tokens. Proper key management is crucial to maintain the security guarantees of JWE.

JSON Web Encryption (JWE) Token: A Comprehensive Guide #

JWE is a widely-used standard for securing data transmission between parties. The industry standard describes a JSON Web Token (JWT) type that uses encryption to protect its payload. It provides confidentiality by encrypting the transmitted data, ensuring only authorized parties can access and read it.

In addition to providing confidentiality, JWE tokens offer integrity protection through message authentication codes (MACs). These codes ensure the receiver can detect tampering with the encrypted payload. Depending on the key management mode, it can also provide authentication.

JWE is relevant for modern AAA concepts in distributed, stateless environments as it enables an exchange of sensitive information statelessly.

The Structure of an Encrypted JWT #

The JWE standard (RFC 7516) is the go-to solution for developers who need to transmit JSON objects over the internet securely. JWE is a standard that defines how to encrypt and decrypt data in JSON format using various algorithms. In this section, I will discuss some of the core concepts of JWE tokens.

A typical, compact serialized, encrypted JWT is a dot (.) separated string that contains five parts:

The JWE Protected Header is a base64url-encoded string representing the token metadata. It describes the JWE, how it was encrypted, and the media type of the encrypted payload. Protected JWE headers can’t be encrypted as they carry all information necessary for decryption.
The JWE Encrypted Key (CEK) is another base64url-encoded string representing the encrypted, symmetric key used to encrypt the payload.
The JWE Initialization Vector (IV) is a base64-encoded unique, random value string used when encrypting the plaintext and helps prevent attackers from exploiting patterns in plaintext or ciphertext.
The JWE Ciphertext, the actual encrypted payload, also base64url-encoded, which was encrypted using the CEK, along with the IV and the additional authenticated data (AAD).
The JWE Authentication Tag (MAC) results from performing authenticated encryption and allows a verifier to prove the integrity of the ciphertext and the AAD (the encoded protected header when using compact serialization). It ensures integrity during decryption.

Support for Symmetric and Asymmetric Encryption Algorithms #

Encrypted JWTs support asymmetric and symmetric encryption techniques to provide end-to-end security for the transmitted data. Symmetric encryption algorithms use the same key for encryption and decryption, while asymmetric algorithms use a pair of keys.

The sender encrypts the plaintext payload using a randomly generated symmetric CEK, then encrypts the key using the recipient’s public key or a shared secret key (a long-lived key encryption key). The recipient can then decrypt the encrypted key using their private secret key and use it to decrypt the payload.

As they are self-contained and carry their corresponding symmetric key (CEK), encrypted JWTs also support hybrid encryption, which allows combining the performance of symmetric encryption with the assurances of public-key cryptography. This flexibility lets developers choose between different encryption algorithms based on their needs.

Nested JWTs #

Another exciting feature of JWE is the ability to create nested JWTs. As the JWE standard allows arbitrary data to be packaged into the payload, it also allows nesting a signed JWT (JWS) inside an encrypted JWT (JWE). Wrapping a JWS into a JWE can be helpful when dealing with asymmetrically encrypted JWE, as these alone do not allow to verify that the JWT was produced by a specific token issuer, merely that someone who possessed the issuer’s public key forged the token. Nested JWTs combine the advantages of JWE and JWS. Symmetrically encrypted JWEs provide all the above security properties without creating nested tokens.

Working with Different JWE Algorithms #

The JSON Web Algorithms (JWA) standard registers all cryptographic algorithms supported by the JWT ecosystem in RFC 7518. The most commonly recommended option for asymmetric key encryption is ECDH-ES, while AES-GCM (with key wrapping) is the recommended alternative for symmetric encryption setups.

JWE with AES Algorithms #

AES (Advanced Encryption Standard) algorithm is still the de-facto standard of a symmetric algorithm that can be used with JWE. It involves using the same secret key to encrypt and decrypt data. The JWE token can be encrypted using AES-GCM (Galois/Counter Mode), which provides authenticated encryption with associated data (AEAD). AES128 should be fine for “short-lived” tokens (<34 million years).

JWE with RSA Algorithms #

RSA (Rivest-Shamir-Adleman) is an example of an asymmetric encryption algorithm supported by JWE. It involves generating a key pair where the public key encrypts data while the private key allows to decrypt it. Commonly used in JWE token contexts is RSA-OAEP (Optimal Asymmetric Encryption Padding).

JWE with Elliptic Curve Algorithms #

Elliptic Curve Cryptography (ECC) is another example of an asymmetric cryptography system supported by JWE. It involves generating a key pair based on elliptic curves rather than prime numbers. The JWE token can be encrypted using ECDH-ES (Elliptic Curve Diffie-Hellman Key Agreement with Elliptic Curve Cryptography) or ECDH-ES+A128KW (ECDH-ES with AES key wrap).

Authenticated Encryption Algorithms #

JWE requires using authenticated encryption (AE) to ensure that the token is encrypted and integrity protected, supporting multiple AE algorithms. Two distinct classes exist, authenticated encryption with AES/CBC/HMAC/SHA and AES/GCM. The latter also supports Authenticated Encryption with Associated Data (AEAD), which provides confidentiality, integrity, and authenticity of the encrypted message and additional authenticated data. It ensures that the message has not been tampered with during transmission.

JWE Token Generation Process #

Encryption Algorithm: Choosing the Right One for Your Needs #

Choosing a suitable algorithm is crucial when generating a JWE token. There are several options available, including AES-GCM, AES-CBC-HMAC-SHA2, and RSA-OAEP. Each algorithm has strengths and weaknesses, so choosing one that aligns with specific needs and requirements is essential.

Generating Keys: Private Key vs Secret Key #

The process of generating keys for JWE tokens differs depending on the form of encryption. Applying symmetric encryption requires generating a random secret key that both the sender and receiver can use to encrypt and decrypt data. Asymmetric encryption involves creating a public-private key pair.

Complete JOSE Header #

The process of generating a JWE token is complex and involves several steps. The first step is the creation of a complete JOSE header that contains information about the encryption algorithm, key management algorithm, key ID (kid), and other critical details. This header is essential because it provides the foundation for creating a secure and valid JWE token.

Encryption & Serialization: Creating Valid JWE Tokens #

Once a suitable encryption algorithm is chosen and keys generated, it’s time to encrypt the payload involving an appropriate initialization vector (IV). After successfully calculating the ciphertext and the corresponding authentication tag, all individual parts are appropriately encoded and joined into their compact serialization format. As JWE deals with various cryptographic algorithms, is somewhat complex, and can become confusing, I recommend leveraging standard libraries to create encrypted and properly serialized JWT.

JWE Token Decryption Process #

Decoding the JWE Compact Serialization #

Decrypting a JWE token starts with decoding the JWE compact serialization. The JWE compact serialization is a string comprising five parts separated by dots: the JWE header, the encrypted key, the initialization vector, the JWE ciphertext, and the authentication tag. It is the most commonly used type compared to the less popular JWE JSON serialization.

The protected header contains information about the encryption and key management algorithms used to encrypt the payload. This information is required to decrypt the token. Once being (base64url) decoded, these claims are accessible for introspection.

Key Decryption #

Access to the private secret key initially used to encrypt is required to decrypt the JWE token. The decryption algorithm referenced in the JOSE header defines the cryptographic procedure for the CEK. Only after decryption can it unlock the actual payload. In the case of public key cryptography, the associated private key must be available. Single-key encryption requires the corresponding secret shared between both parties to be present.

Payload Decryption #

The IV value initializes the cipher instance with an appropriate mode like CBC, GCM, etc. The previously obtained JWE encrypted key (CEK) can decrypt the JWE ciphertext value, yielding a plain text (often a JSON object) after successful decryption. The integrity of the ciphertext and its additional authenticated data (AAD), in this case, the JWE header elements, is verified using the authentication tag value provided in the last part of the serialized JWE object.

Security Considerations #

Authentication Tag and Additional Authenticated Data #

One key feature that makes JWE tokens secure is using an authentication tag and additional authenticated data (AAD). The authentication tag is a small piece of data at the end of the encrypted JWT, which allows recipients to verify that the message has not been tampered with during transmission. AAD provides an extra layer of security by enabling the sender to include additional data in the encryption process that the recipient will verify.

However, not all JWE tokens have an authentication tag or AAD. There are JWA encryption algorithms that do not use an authentication tag, in which case the value is supposed to be an empty octet sequence.

Leaky Headers #

Another potential security concern when using JWE tokens is custom header elements. JWT headers include public claims by design that are integrity protected at max. Using customer header claims means they can potentially leak sensitive information if mismanaged. It’s crucial to handle custom header claims carefully and only include necessary information. If confidentiality is needed, custom fields belong in the payload. If there is a need for public hints, the header metadata is just fine.

Key Management and Token Expiry #

Proper key management is essential for maintaining the security of JWE tokens. Identity providers must store the long-lived key management keys securely and rotate them regularly to prevent unauthorized access, as compromise might result in disclosing all contents protected with that key.

Similarly, successful attacks on the CEK will strip all confidentiality properties from the corresponding token. Implementing token expiry to limit the amount of time token usage before it becomes invalid is necessary for all everyday use cases.

Weak algorithms #

The JWE specification includes a limited range of supported encryption algorithms. And also, the officially supported ones rarely convince security experts: The ECDH-ES algorithm allows an attacker to recover the private key if not adequately implemented. GCM is likely fragile, as Google researchers claim. And RSA encryption with PKCS1v1.5 padding is broken.

When leveraging JWE, I recommend supporting short notice and timely transitioning to alternative encryption algorithms.

Comparison of JWE and Other JSON Security Standards #

JWE vs JWT #

While both JWE and JWT are part of the JSON Object Signing and Encryption (JOSE) security framework, they serve different purposes. As mentioned, JWEs provide JSON data encryption, while unsecured JWTs (RFC 7519) provide no particular security properties. In identity and access management (IAM) scenarios where a client sends a token to a resource server as proof of identity, JSON Web Tokens commonly appear in their signed JWS form.

JWE vs JWS (JSON Web Signature) #

JWS is a JSON-based format for representing digital signatures (RFC 7515). JWS assures integrity and authentication, but it does not provide confidentiality. JWS tokens contain three elements: the JOSE header, payload, and signature. On the other hand, JSON Web Encryption (JWE) is a standard for encrypting JSON data. JWE tokens protect sensitive data by also providing confidentiality.

JWE vs JWK (JSON Web Key) #

JWK is another standard in the JOSE family (RFC 7517) that defines JSON format for cryptographic keys. A JWK Key Set (JWKS) can contain keys used for either encryption or signing, depending on their type. JWKs can be used with both JWS and JWE standards to provide cryptographic operations such as decryption or verification of digital signatures.

Practical Applications of JWE Tokens #

The nature of JWE tokens makes them ideal for enabling stateless information exchange in modern AAA processes or exotic one-time-token (OTT) scenarios. In this section, I will discuss some practical applications of JWEs.

Bearer Token: A Powerful Authentication and Authorization Tool #

JWEs often appear as bearer tokens to authenticate and authorize access to protected resources. Bearer tokens are powerful tools because they allow users to access resources without repeatedly providing credentials. Instead, the bearer token serves as proof of identity and authorization.

JWE in OAuth2 and OIDC #

OAuth2 and OpenID Connect (OIDC) are widely used authentication/ authorization protocols, often used for securing web APIs. They allow users to grant access to their resources without sharing their credentials with third-party applications. These protocols can use JWE Tokens to provide an additional layer of security by encrypting the access token. Enforcing clients to treat them as genuinely opaque tokens allows the token issuer (authorization server) to transport sensitive information like PII statelessly. At the same time, it also ensures that even if an attacker intercepts the token, they cannot read its contents without the decryption key.

JWE for Data at Rest #

Data at rest refers to data stored on disk or other storage media. This data is vulnerable to attacks if it is not adequately secured. Although not common, JWE tokens can encrypt sensitive data before storing it on disk, ensuring that even if an attacker gains access to the storage media, they cannot read its contents without the decryption key.

Conclusion #

JSON Web Encryption (JWE) is a powerful tool for ensuring the confidentiality and security of data transmissions. JWE tokens carry an encrypted payload between multiple parties. The secured data can only be read with the proper decryption key, even if intercepted. Authenticated encryption ensures that sensitive information remains confidential and tamper-proof, providing both senders and receivers peace of mind.

The use cases for JWE tokens are varied and versatile. Use JWE in situations where confidential data exchange is necessary. When used as a bearer token within modern authorization and authentication frameworks like OpenID Connect (OIDC), JWE tokens transport sensitive information often as access tokens.

Frequently Asked Questions (FAQs) #

What is the purpose of JWE? – JWE tokens securely transmit data between parties in a JSON format. They provide confidentiality, integrity, and authenticity to the transmitted data.
How does JWE differ from JWT? JWE focuses on encrypting the payload, while plain JWT provides no additional security properties.
What are standard encryption algorithms used in JWE? Some common encryption algorithms include RSA-OAEP, AES-GCM, and ECDH-ES.
Is it safe to use JWE tokens for sensitive data? Yes, as long as proper security measures are taken, such as using robust encryption algorithms and protecting the encryption and decryption keys.
Can JWE be used with other JSON security standards? JWE can be combined with other JOSE, such as JWS, to support even more complex scenarios with nested JWTs.

JWT vs OAuth 2.0: Understanding the Key Differences

Wed, 24 May 2023 00:00:00 +0200

TL;DR #

OAuth 2.0 is an open standard that describes an authorization framework. It allows a third-party application to access a user’s resources without user credentials.
JWT (JSON Web Tokens) is a standard that describes a JSON-based token format used to securely transfer information between two parties across an insecure environment.
Combining OAuth 2.0 and JWT: JWT can be integral to the OAuth 2.0 framework . In fact, JWT has often been used as the bearer token in OAuth 2.0 implementations.
OpenID Connect (OIDC): Modern authentication and authorization mechanisms leverage the OAuth 2.0 fundamentals with JWT tokens by following OpenID Connect protocols.

Introduction to JWT vs OAuth 2.0 #

Most people encounter OAuth2 and JSON Web Tokens (JWT) in the context of authentication and authorization for web applications. While both concepts nowadays get used together, comparing OAuth2 vs JWT is like comparing apples to kittens.

10 years after the last update to the OAuth 2.0 Authorization Framework standard (RFC 6749) and over eight years after JSON Web Tokens got unleashed to the world, there is still a lot of confusion around these two widespread open standards among software engineers and security engineering novices. In this article, I will explain why comparisons like “JWT vs OAuth 2.0” or questions like “OAuth vs JWT which is best” make little sense.

What is OAuth2? #

OAuth2 is an open standard describing an authorization framework that allows a third-party application to access a user’s resources without giving them the user’s credentials. The keywords here are authorization protocol and delegated access. It does this by providing the concept of access tokens that can be used by a client application to access protected resources (like an API) exposed by a resource server on behalf of the resource owner (a user). These opaque tokens are issued by an authorization server after the user grants permission to the third-party application.

What is JWT? #

On the other hand, the JWT standards describe a JSON-based token format and how it can securely transfer information between two parties across an insecure environment (like HTTP or HTTPS). Their multipart JSON format structure allows JWTs to carry custom claims as payloads and additional cryptographic accessories. They are self-contained and usually occur in their JSON Web Signature form, signed with a secret key or public/private key pair. I wrote about “The Purpose of JWT” a few years ago.

When to Use OAuth 2.0 vs When to Use JWT #

Use OAuth 2.0 with HTTPS when authorizing third-party access.

OAuth 2.0 is a protocol that allows users to grant limited access to resources on one site, such as Facebook, to another location or application, without sharing their credentials or giving them complete control over their account. It provides a secure way of authorizing third-party access to your resources by using access tokens in the form of bearer tokens.

After the resource owner grants permission for the client application to access their resources using OAuth2, the responsible authorization server issues the proof of authentication. These tokens are then sent with each request made by the client application to the resource server, verifying them and granting or denying access based on the services requested and claims provided.

Bearer tokens are a type of access token that can be used by arbitrary parties in possession of them to gain access to the protected resources they represent. They do not contain any cryptographic proof of authenticity other than possession itself, so they must be kept secret and transmitted securely.

OAuth 2.0 is an excellent choice when you must permit controlled interaction between third-party applications or services managed by different entities or individuals with your system without compromising sensitive information or risking unauthorized access. This is possible through various security mechanisms such as opaque tokens, bearer tokens, identity servers, and refresh tokens.

Use JWT when securely transmitting information between parties in a stateless form.

JSON Web Tokens are basically use cases agnostic and can generally be used for securely transmitting information between parties in stateless form. It provides a simple way of representing claims (e.g., user identity, permissions) as JSON objects that can be signed and/or encrypted using industry-standard algorithms.

JWTs are often used for transporting proof of authenticity across multiple domains or applications without storing session data on the server side, significantly contributing to performance. They are also helpful for implementing single sign-on (SSO) functionality, where a user logs in once and gains access to multiple applications or services without claiming their identity again. And this is basically where OAuth 2.0 and JWT touch on each other.

Combining OAuth 2.0 and JWT: How to Use Them Together #

The apparent overlap between JWT and OAuth 2.0 springs from a misunderstanding of their distinct roles in digital communications. JWT can be an integral part of the OAuth 2.0 framework. In fact, JWT often serves as the bearer token in OAuth 2.0 implementations, becoming the vehicle by which authorization information is conveyed.

JWT as Bearer Token #

JWTs can be used by an app as OAuth2 bearer tokens to enable stateless authentication and local authorization by a resource server to grant access to a protected resource.

Bearer tokens are a type of token that is widely used in authentication protocols like OAuth 2.0. They are used to grant access to protected resources, and they come in two types: access tokens and refresh tokens. While access tokens are short-lived, refresh tokens can be renewed, allowing users to maintain their session for an extended period.

JWTs are often used in combination with OAuth 2.0 as a means of transmitting state and user data (claims) between the authorization server and the resource server. They can also be used for client-side authentication, where a JWT is issued by an identity provider after successful login and then sent to the client application, which uses it to authenticate itself on behalf of the actual user with other services.

Advantages of Using JWT with OAuth 2.0 #

One significant advantage of using JWT with OAuth 2.0 is eliminating the need for multiple tokens for different app purposes. One token can contain all the necessary information for authentication and authorization purposes.

Another benefit can be improved performance through stateless authentication. Since JWT tokens are self-contained and signed with a secret key or public/private key pair, there is less reliance on external servers for validation and introspection. JWT is very suitable for stateless applications as they relieve the server side from the need to store any particular session data between requests from the clients.

Instead, all necessary data is carried around within each JWT token itself, making it easy for clients and servers alike to verify its authenticity without looking up anything outside of it. This reduces the number of database lookups required during token verification, leading to faster response times, increased reliability due to fewer bottlenecks, and a potentially cleaner architecture.

Which Bearer Token Format is Right for You? #

Choosing the suitable OAuth 2.0 access token format can be a daunting task. Both stateful tokens and stateless JWT have their strengths and weaknesses. It ultimately depends on specific use cases, requirements, and infrastructural preconditions.

Modern authentication and authorization mechanisms leverage the OAuth 2.0 fundamentals together with JWT tokens by following OpenID Connect (OIDC) protocols, which is an extension on top of OAuth 2.0 that introduces the concept of an identity provider (aka identity server) and uses JWTs instead of opaque tokens.

JWT + OAuth2 = OpenID Connect (OIDC) #

Big tech organizations such as Google, Facebook, and Microsoft are OIDC power users:

Google Identity uses OIDC and its identity token to transport user details.
Facebook also uses OIDC with JWTs in its Graph API authentication mechanism.
Microsoft’s Azure Active Directory (AAD) also leverages the JWT token to implement OIDC.

Whether you choose classic OAuth 2.0 with opaque, non-JWT tokens, OAuth 2.0 with JWT bearer token, or OIDC, make sure you understand how these frameworks work under the hood, embrace their core concepts and get your implementation externally certified to ensure maximum security for your users’ data while also providing seamless access to your application’s features and resources. The better way, however, is to outsource the authentication to Google, Microsoft, Okta, or someone else and let them deal with all the nifty little details in these specifications.

Conclusion: Choosing Between JWT and OAuth2 #

Combining OAuth 2.0 and JWT can give you the best of both worlds. OpenID Connect is built on both open standards, embracing OAuth 2.0 concepts to delegate access with external services while using JWT as a bearer to transport claims from the authorization server to resource servers for stateless authorization.

JWTs allow client-side introspection of ID tokens, enable resource server serving APIs to verify access tokens locally, and even be used as refresh tokens. Although slightly controversial, JSON web tokens are versatile and can be used as one-time token (OTT).

Where do OpenID Connect implementations break?

Mon, 15 May 2023 00:00:00 +0200

Latest change (2026-10-13): Rewritten as a field-guide entry: question title, short answer, key findings and evidence table. Study summaries kept and extended with numbers from the thesis abstract.

Short answer: Implementations break mostly where tokens and redirects get checked. Documented attacks on relying parties include token substitution, key confusion and replay, and attacks on providers include redirect URI manipulation, PKCE downgrade and sub claim spoofing. Certification doesn’t rule these out, as a 2020 lab analysis of OpenID Certified implementations disclosed 12 flaws.

Key findings #

Testing 6 OpenID Certified identity providers and 8 service providers against 11 service provider attacks and 7 identity provider attacks uncovered 12 implementation flaws.

Source: Fries, Security Analysis of Real-Life OpenID Connect Implementations (Master's thesis, Ruhr-University Bochum, 2020)

Link to this finding Save as image (PNG, 1200 by 630 pixels)

Mladenov and Mainka classify session overwriting and IdP confusion as flaws in the OpenID Connect specification itself, separate from implementation bugs.

Source: Mladenov and Mainka, OpenID Connect Security Considerations (Ruhr-University Bochum, 2017)

Link to this finding Save as image (PNG, 1200 by 630 pixels)

The attacks in the OpenID Connect Security Considerations report work for a web attacker who sends ordinary HTTP requests and has no control over the network.

Source: Mladenov and Mainka, OpenID Connect Security Considerations (Ruhr-University Bochum, 2017)

Link to this finding Save as image (PNG, 1200 by 630 pixels)

Evidence #

OpenID Connect security studies
Study	Year	Sample	Method	Finding
Security Analysis of Real-Life OpenID Connect ImplementationsRuhr-University Bochum	2020	6 identity providers, 8 service providers	Docker lab with PrOfESSOS, automatic and manual tests	18 attack types tested; 12 implementation flaws disclosed.
OpenID Connect Security ConsiderationsRuhr-University Bochum	2017	n/a	Technical report on specification and implementation flaws	Catalogues attacks on clients and providers with defence recommendations.

What to do #

For engineers #

On the relying party:

Validate every ID token: signature with a key from the expected issuer’s key set, algorithm, issuer, audience, expiry and nonce. Signature manipulation, key confusion, token recipient confusion and replay attacks all exploit a missing check. My essays on JWKS and the purpose of JWT cover the token side.
Bind each login to the browser session that started it, and remember which identity provider you sent the user to. Session overwriting and IdP confusion exploit clients that don’t.
Identify users by issuer and subject together, never by subject or email alone.

On the OpenID provider:

Compare redirect URIs exactly against the registered values.
Enforce PKCE for clients that started with it, so an attacker can’t downgrade the flow.
Accept each authorization code once and only from the client it was issued to.

For product and UX #

Treat “OpenID Certified” as a conformance signal, not a security audit. Fries tested certified implementations and still disclosed 12 flaws. When you choose a library or vendor, ask for penetration test results that cover these attack classes.
If your product offers several identity providers, show users which one they’re signing in with. IdP confusion attacks rely on the client mixing them up.

The studies in detail #

Security Analysis of Real-Life OpenID Connect Implementations #

In this Master’s thesis from December 2020, Christian Fries presents a Docker-based lab environment for developers and penetration testers. The lab helps to find security flaws in real-world OpenID Connect Certified service provider and identity provider implementations, and it includes the PrOfESSOS tool for automatic tests. Fries selected 6 identity providers and 8 service providers that support the implicit and hybrid flows. He tested them against 11 service provider attacks and 7 identity provider attacks and disclosed 12 implementation flaws to the developers.

The thesis also describes common threats and attack scenarios. These include single- and cross-phase attacks on relying parties, like token substitution, key confusion and replay attacks. It also covers attacks on OpenID providers, like message flow confusion, PKCE downgrade and sub claim spoofing.

Read the paper (PDF)

OpenID Connect Security Considerations #

In this 2017 technical report, Vladislav Mladenov and Christian Mainka from Ruhr-University Bochum look at OpenID Connect specification flaws and implementation issues that open up attack vectors. They outline attack scenarios like session overwriting, redirect URI manipulation and token recipient confusion, and give recommendations for defending against them.

Read the paper (PDF)

Step-Up Authentication: Elevating Security with OpenID Connect (OIDC)

Sun, 14 May 2023 00:00:00 +0200

Security measures are effective when they cause the least friction while providing the highest level of security necessary for the targeted, user-friendly business process. Asking for too little gives users (or whoever is posing as them) too much freedom, but asking for too much, especially up front, generates obtrusive friction.

Minimal friction is essential to success, especially in conversion-sensitive flows like sales funnels. Services or apps are meant to be simple to access, and customers who want to utilize a product or purchase within as little time as possible may do so with as little friction. Making authentication even slightly more complicated risks alienating prospective customers.

What is Step-Up Authentication? #

Step-up authentication is one way of balancing friction and security that has received much attention and application in recent years. Step-up authentication ensures that users can access specific resources or execute the most typical actions with a single set of credentials. Users will be prompted for additional authentication factors when requesting to access sensitive resources or initiating privileged operations.

The Rationale Behind Step-Up Authentication #

Step-up authentication aims to tailor identity requests to the value of the resource and the local risk level and anticipated impact if it is compromised. By enabling risk-based authentication, step-up authentication allows organizations to provide easy access to one tier of non-critical resources while providing secure access to another.

As a result, security stays out of the way most of the time and only intervenes when further proofs of authenticity are absolutely required. This makes authentication work for both organizations and customers since both can be certain that their most sensitive resources are safe and secure.

It also opens new ways to conduct authorization by allowing organizations to privilege access for paying users.

Step-Up Authentication vs Single-Factor Authentication #

Although ubiquitous, single-factor authentication (SFA) frequently falls short of offering adequate security against common identity attacks. This traditional approach, which usually requires only a username and password, is widely regarded as insufficient due to its susceptibility to breaches ranging from brute-force attacks like password spaying to phishing schemes.

In contrast, step-up authentication provides a more dynamic and context-sensitive security barrier. Instead of depending on a single, static layer of protection, it adjusts to changing risk levels by providing additional verification steps as needed. Step-up authentication provides a more sophisticated and scalable approach to security, delivering a higher level of protection without losing user convenience under normal conditions.

Step-Up Authentication vs Multi-Factor Authentication #

In many security-conscious environments, multi-factor authentication (MFA) has become the gold standard, requiring users to present a second factor (or multiple authentication factors) to access their online accounts. While MFA considerably improves security over single-factor authentication, it may cause user annoyance, particularly if additional verification steps are required for every login or transaction, regardless of the associated risk.

Step-up authentication is a flexible form of multifactor authentication, adding additional security layers only when necessary, such as during high-risk transactions or unusual account activity. This method ensures essential security requirements and improves the user experience by reducing unnecessary disruptions.

Step-Up Authentication vs Adaptive Authentication #

Adaptive authentication, like step-up authentication, is a more intelligent, context-aware approach to account security. It dynamically increases the level of necessary user authentication based on a risk assessment of each individual login or access attempt, considering parameters like geolocation (e.g., impossible travel), IP reputation, device characteristics, and behavior patterns, or user’s risk profile.

However, there is a subtle distinction between the two. While responding to perceived risks, step-up authentication often initiates additional authentication processes in predetermined conditions and based on static risk assessments, such as when a user attempts a high-value transaction.

In contrast, adaptive authentication uses advanced risk analysis algorithms, sometimes powered by artificial intelligence or machine learning, to assess the need for extra real-time authentication steps. While both give a more personalized and responsive approach to security compared to previous static techniques, Adaptive Authentication provides a more granular and automated risk assessment, possibly providing a higher level of protection and user experience when applied successfully.

How Step-Up Authentication Works #

Step-up authentication generally requires multiple stages of verification. When a user initiates an action that requires enhanced security, such as accessing confidential documents or conducting financial transactions, the system prompts the user for multi-factor authentication. This step up can manifest itself in a variety of ways, including, but not limited to:

Two-Factor Authentication (2FA) – To verify a user’s authenticity, this method combines something the user knows (e.g., a password) with something the user owns (possession factor), such as a unique code generated by a mobile app.
Biometric Authentication – Biometric authentication delivers high security and convenience for users by using unique biological traits (inherence factor) such as fingerprints, facial recognition, or iris scans.

Implementing Step-Up Authentication #

In traditional authentication systems, step-up authentication was handled by integrating the relevant business logic within the web applications. Custom engineering efforts and heterogeneous implementations could have used more resources by neglecting to reuse well-tested code and incurring ongoing maintenance costs. Still, they also increased the possibility of security flaws.

Since federation protocols like OpenID Connect (OIDC) are becoming increasingly popular for modern applications that want to improve security by relying on a reliable identity provider, there are also better, standardized options for implementing step-up authentication.

Step-up Authentication with OpenID Connect #

OIDC is an open standard with built-in support for relying parties (RP) that require more potent authentication methods (AMR) to be used depending on the authentication context classes. Because conventional federation protocols such as OIDC are business context agnostic and do not track every user interaction, business apps must initiate step-up scenarios independently.

Forced Re-Authentication Methods #

Following successful authentication, IdPs frequently provide long-running login sessions bound to user agents. The goal is to eliminate consumer friction by removing the need for regular active credential authentication. However, depending on an RP’s local risk assessment, certain business operations may require the most recent functional proof of authenticity check to be no more than a particular period old.

Relying parties use the optional authentication request variable max_age to communicate session age expectations to an IdP service. OIDC-compliant IdPs ensure that all session age requirements are met by requiring authentication as needed.

GET /authorize?
 response_type=code
 &scope=openid%20profile%20email
 &client_id=s6BhdRkqt3
 &state=af0ifjsldkj
 &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
 &max_age=300 HTTP/1.1
Host: server.example.com

Requiring re-authentication of existing sessions every time a user attempts to access sensitive information or protected areas of an application adds friction to the user experience. Session elevation can be used to successfully achieve a balance between a smooth user experience and security considerations.

The authentication context class concept allows apps to build such scenarios and coordinate with an identity provider (IdP) for smooth step-up service in a declarative policy-driven method.

Authentication Context Class Reference (ACR) #

The optional authentication request parameter acr_values is a space-separated list of ACRs that determines the client application’s minimum degree of authentication. If the parameter is present, the IdP takes all measures necessary to verify and match the requested class. Users may be asked to re-authenticate using additional or different authentication methods to achieve this objective.

The authentication context class met by the completed identity authentication is returned as the ACR claim value within the provided identity token, which can then be utilized for authorized purposes by the RP.

ACR values and their semantics must be established, aligned, and documented between IdP and RPs out of the band. Only then business owners effectively employ them to precisely determine what ACR relates to the local risk assessment of their specific business operations.

Authentication Level Elevation #

Access to sensitive information and operations must be logged appropriately and authorized by resource servers. Verifying the validity of the provided bearer token is required to ensure that a client is eligible to undertake a specific operation.

The goal of session authentication and assurance level elevation is to provide a relatively seamless user experience by maintaining a minimum level of assurance for a user session when the user first authenticates to the application and then raising their authenticity levels based on local risk assessments:

Assuming that a user successfully established a session after logging in with a username and password and now attempts to access a sensitive resource, they are prompted to apply extra authentication factors.
The session is upgraded to a higher assurance level after a successful step-up using an additional authentication method.
Because their session is already at the raised authentication levels, no extra authentication challenge will be prompted the next time users enter the sensitive section within the specified duration.

GET /authorize?
 response_type=code
 &scope=openid%20profile%20email
 &client_id=s6BhdRkqt3
 &state=af0ifjsldkj
 &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
 &acr_values=mfa
 &max_age=300 HTTP/1.1
Host: server.example.com\

Conclusion #

Step-up authentication aims to adapt authentication requirements to the significance associated with a resource and the level of risk if it is exposed. It is one way to strike a balance between friction and security by allowing customers to continue using already known, established, and understood authentication concepts (username and password, for example) to access regular resources while prompting them for additional proof of authenticity and a different form of two-step authentication (such as confirmation via email or push notifications) in the context of more sensitive business operations (such as financial transactions or accessing sensitive data).

Enabling session authentication level elevation and step-up authentication can resolve the target conflict of providing customers with a smooth experience on the one hand and enforcing more significant security standards for specified operations or resources on the other.

Frequently Asked Questions (FAQs) #

What are the minimum requirements to implement Step-Up Authentication? #

First and foremost, a reliable and secure primary authentication mechanism, such as a secure password system or biometric identification method, is essential. Second, an additional authentication method, such as text message verification, email confirmation codes, security questions, or biometric checks, must be available and compatible with the user base.

The user’s technological capabilities and the amount of security required to determine which to utilize. Third, an effective risk assessment system must be established to detect circumstances requiring more verification. Finally, to support all the complex procedures involved in step-up authentication, an IT infrastructure that is both adaptable and secure is necessary.

How does Step-Up Authentication improve user experience? #

Step-up authentication is intended to improve the user experience by requiring further verification only when necessary. Step-up authentication, as opposed to standard static multi-factor authentication, which requires additional steps every time a user signs in or performs specific actions, only increases security measures in the context of higher-risk activities.

This means that for most ordinary actions, consumers may enjoy a frictionless, seamless experience without being burdened by additional security precautions. However, when it comes to more sensitive procedures, such as changing personal information or completing large transactions, consumers can welcome the added degree of protection, knowing their accounts and data are secure.

How can Step-Up Authentication prevent data breaches? #

Step-up authentication is a powerful technique that adds complexity and layers to the authentication process. Step-up authentication adapts to the perceived risk level of a user’s activity. This means that even if an attacker successfully steals or guesses a user’s primary credentials, they will still face additional, often unanticipated, obstacles before getting access. Many cyberattacks are deterred by this since it considerably increases the work and skill required to compromise an account.

Passwordless: Critical Notes on FIDO2 Passkeys

Mon, 08 May 2023 00:00:00 +0200

Passkeys are currently on everyone’s lips, thanks to recent announcements to enable Passkeys for authentication on Google accounts. And, while the passwordless hype train did not stop in front of my desk either, there are some problems surrounding the imminent password killer, disregarded mainly by the relatively uncritical media coverage. In this essay, I’ll consider some of the biggest concerns.

I briefly mentioned Passkeys in my recent piece about passwordless authentication, so I’ll keep this introduction brief. Let’s get started!

Introduction to FIDO2 & Passkeys #

The FIDO Alliance developed FIDO2 as an open standard that enables secure and user-friendly passwordless authentication. One of FIDO2’s key goals is to provide passwordless authentication, removing the need for users to remember and manage multiple passwords. Members of the FIDO Alliance include the whole Big Tech ecosystem, from 1Password through Amazon, Apple, Google, Meta, and Microsoft, as well as Yahoo and Yubico.

Phishing-resistant Passwordless Authentication #

The FIDO master plan is to turn every mobile phone into a phishing-resistant, roaming authenticator by augmenting the FIDO WebAuthn specs with a protocol that uses Bluetooth to communicate between the FIDO authenticator (a mobile phone) and the device from which a user is attempting to authenticate. Specialized security keys (hardware tokens like YubiKeys) will be rendered obsolete.

The term “Passkeys” refers to the credentials used in this authentication procedure based on cryptographic concepts. Passkeys for FIDO2 allow users to authenticate themselves without entering a long password, lowering the risk of password-related security breaches.

Public-Key Cryptography #

Unlike many other passwordless login approaches, FIDO2 Passkeys provide a robust authentication mechanism immune to phishing attacks, man-in-the-middle, and replay attacks. This is accomplished through public-key cryptography, a cryptographic technique that employs two keys: a public key and a private key.

Data is encrypted using the public key and decrypted using the private key. In FIDO2 authentication, the private key is securely maintained on the user’s device, while the public key is registered with the online service. The Passkeys protocol defines proof of possession challenges that allow holders of a public key to verify whether the authenticating actor owns the corresponding private key (possession factor). This is a more secure solution than traditional password-based authentication methods (knowledge factor) in most end-user use cases.

Even if your favorite e-commerce site or platform is compromised, malicious actors will only have access to the public component of your key pair, which they will find absolutely useless.

Biometrics #

Now that the most essential authentication proof is stored on a mobile device, FIDO experts anticipate that Big Tech companies will protect access to the private keys as they protect screen lock, with biometric authentication incorporated into the user’s personal device OS. Using Face ID, Touch ID, or any other equivalent facial recognition or fingerprint scanning technology on a Microsoft or Android device to gain access to the valuable private key material, which is then used to sign in with a relying party, effectively results in a multi-factor authentication (MFA) process, combining an inherence factor and a possession factor.

Passkeys Controversies #

Possession & Biometrics over Knowledge #

The most crucial conceptual objective of Passkeys is to shift the broad consumer market away from knowledge-based authentication systems and toward possession-based authentication systems. Although this is undoubtedly a quantum leap forward in account security, far-reaching repercussions may still need to be fully recognized.

For example, something only you know cannot be taken away as quickly as something physical that you own. A secret in someone’s head cannot be found anyplace else and can only be gained from that individual. Of course, there’s blackmailing, “rubber-hose cryptanalysis,” and other methods, but these appear to take much more effort than merely having access to an unlocked cellphone.

Losing that knowledge component makes you more vulnerable to police seizures of electronics and keys, for example. Forcing someone to give up a password is considered a violation of the Fifth Amendment to the United States Constitution by courts in the United States. However, forcing someone to unlock biometrically secured devices is entirely legal. A similar situation might exist in other jurisdictions as well.

While the combination of possession- and inherence factors that FIDO Passkeys promise provides a significant convenience advantage over password-based authentication methods, they appear less effective against close-proximity, physical attacks.

Device Lock-in #

Possession-based systems, in general, rely on tangible items that can be misplaced, stolen, or damaged, potentially locking users out of their accounts.

The FIDO Alliance anticipates that FIDO authenticator providers, particularly influential organizations who embed FIDO authenticators within their operating systems, will make the Passkeys consumer market usable by overcoming the difficulty of making FIDO credentials multi-device available.

Of course, for all of this to function, you’ll need a reliable, modern computer or phone. This means owning a current iPhone, Pixel, or computer that supports Windows Hello, Apple Touch ID, or other biometrics. You also need multiple devices because you are only safe against single device failure if you have a backup device.

Passkeys are likely to be risky to use, if not utterly inaccessible to the poor, underprivileged, or anyone who does not own or operate their own devices.

Vendor Lock-in #

Vendor lock-in shouldn’t be necessary by design, but it may be in reality. Even the FIDO Alliance does not guarantee interoperability when syncing the cryptographic keys of FIDO credentials between devices from different vendors. This is where the additional cross-device authentication Bluetooth protocol comes into play because FIDO believes that users will always have another (backup?) device nearby with all the necessary Passkeys.

This is at least a partial vendor lock-in and disregards the reality of life for many individuals outside of Silicon Valley.

Proprietary-only #

The FIDO Passkey standard deliberately excludes any explicit vendor agnosticism. Implementations still heavily rely on proprietary software embedded into Apple, Google, Microsoft, and others’ devices and solutions. The general strategy results in Big Tech creating and overseeing the key storage. There are no OSS implementations for creating and exchanging keys yet.

As a result, the Passkey concept pushes data ownership one step closer to the Big Tech industry. Taking another vital element of informational self-determination out of the hands of end users by favoring possession- and biometric-based authentication factors over something that is actually available solely to the user is an intentional feature of Passkey rather than a flaw.

100% Trust in Big Tech #

Although FIDO specifies privacy principles that must be followed in designing and implementing FIDO authenticators, clients, and servers, it is still determined how strictly these guiding principles will be enforced and by whom.

The fact that Passkeys is strengthening the need to trust massive tech corporations, whose business model frequently entails selling data and information, is critical. Having FIDO credentials, which basically log end-users into every service they use while vowing not to do evil with them, necessitates some level of trust by the users.

Conclusion #

FIDO2 Passkeys provide a passwordless authentication solution that is secure, user-friendly, and scalable. Unlike passwords, they provide increased protection against common threats and a better user experience for those who can afford it by utilizing public-key cryptography. While there are compelling reasons to join the password-killer bandwagon, and I honestly believe that Passkeys will solve many problems for the general “my password is password” end-user market, there is an undercurrent.

Despite being a multi-national tech industry association, some people see the FIDO Alliance and their Passkeys as another large Silicon Valley solution that doesn’t care about all their users. Potential downsides, such as device dependence, compatibility, and interoperability difficulties, contribute to this debate and should be considered when advocating for FIDO2 Passkeys.

Given the widespread support and work that Big Tech is putting towards modern passwordless authentication, I am confident that adoption rates will skyrocket soon. And some security-conscious individuals will continue to place their stack of unique, complex passwords in a credible password manager with 2FA as a second line of defense rather than a select handful of Big Tech gatekeeping providers.

I advise everyone else to wait until passkeys gain broader support and for the ecosystem to mature before going all-in! Only switch to Passkey-only authentication once you know how it works, how to set it up, and how to back it up.

FAQs #

What is FIDO2? #

The FIDO Alliance created FIDO2, an open standard to enable secure and user-friendly passwordless authentication using public-key cryptography.

How do FIDO2 Passkeys work? #

Upon registration, FIDO2 Passkeys produce a one-of-a-kind public-private key pair on the user’s device. The public key is supplied to the web service, while the private key is kept protected on the device. During authentication, the machine uses its private key to satisfy a cryptographic challenge given by the service, and the service verifies the signature using the stored public key.

What are the benefits of FIDO2 Passkeys? #

FIDO2 Passkeys improve security, user experience, and scalability across various devices, platforms, and services.

What are the potential drawbacks of FIDO2 Passkeys? #

Device dependence, which could result in users losing access to their accounts if their device is lost or broken, and compatibility difficulties, as not all online services offer FIDO2 authentication yet, are potential downsides of FIDO2 Passkeys. Switching from knowledge to possession factors has its own set of issues.

Can I use FIDO2 Passkeys on multiple devices? #

Yes, FIDO2 Passkeys can be used on numerous devices as long as they support FIDO2 authentication and the online service supports multiple device registrations.

Passwordless Authentication: Future of Cybersecurity

Sun, 07 May 2023 00:00:00 +0200

In the context of internet security, implementing passwordless authentication really is a game changer. Say goodbye to traditional, complicated, and insecure passwords! It’s time for us to investigate the myriad advantages of implementing passwordless authentication and understand why it’s necessary for improving cybersecurity.

In this detailed introduction, I’ll delve deep into the realm of how passwordless authentication works, its various forms, and how it might improve security. Let’s get this party started!

Passwordless Authentication: A New Era of Security #

What is Passwordless Authentication? #

Passwordless authentication refers to a way of validating a user’s identity that does not require the use of passwords. Instead of remembering long strings of characters, this solution depends on biometrics, one-time codes, or hardware token for verification. By minimizing the usage of weak or reused passwords, it gives a more secure and user-friendly experience.

Passwordless Authentication vs. MFA #

Multi-factor authentication (MFA) is a layered authentication method that includes at least two of the following authentication factors:

something the user knows (knowledge-based, such as a long password),
something the user has (possession-based, such as a hardware token), or
something the user is (biometric, such as a retinal scan).

This approach assures that even if one authentication factor is compromised, an attacker must still penetrate the additional strong authentication layers to get unauthorized access.

Passwordless authentication occurs whenever a user or device is authenticated using a method other than a knowledge-based authentication process. It is related to MFA in the sense that it can be utilized as a supplementary verification requirement, often on top of a user’s account and passwords, in any multi-factor authentication process.

Why is Passwordless Authentication Important? #

In the age of rampant cyberattacks, securing online accounts has never been more important. Passwordless authentication has several advantages over traditional password-based approaches:

Enhanced security – Passwordless authentication solves the inherent risks of password-based systems by eliminating the requirement for traditional login credentials. Password reuse, weak passwords, compromised credentials and phishing scams become obsolete when users no longer need to remember, store, or enter passwords in order to access their accounts. Credential stuffing and other classical brute-force attacks come to nothing.
Improved user experience – By removing the need for passwords, users are relieved of the tedious task of creating, remembering, and keeping several complex passwords for different accounts. There will be no more forgotten passwords, lengthy password resets, or irritating lockouts due to erroneous password authentication. With no need for corrupt password strength meters or restrictive password-based authentication policies, there is less friction during sign-up and sign-in processes. Your conversion rate will be happy!

How Does Passwordless Authentication Work? #

Passwordless authentication may appear to be a difficult concept at first, but it is actually a comprehensive authentication method, that streamlines and secures user access to online services and apps. Passwordless authentication, as opposed to standard passwords, uses a combination of modern technology and unique identifiers to authenticate a user’s identity.

Typically, the process starts with the user initiating an authentication request, such as signing into an account or accessing a protected resource. Instead of requesting a password, the system demands the user enters an alternative, pre-configured authentication factor, such as a fingerprint, face recognition, or a one-time passcode. These solutions are more secure and personal by definition, making it extremely difficult for attackers to impersonate the legitimate user and steal credentials.

When the user enters the requested authentication factor into the login box, the system verifies the information and, if it matches, grants the user access. The beauty of passwordless authentication is its ability to simplify the login process while also increasing security, resulting in a smooth and secure user experience that is changing the way we interact with the digital world.

Types of Passwordless Authentication Methods #

Biometric Authentication Factors #

Biometric authentication is based on distinguishing bodily traits such as fingerprints, facial recognition, or iris scans. The controversial authentication method gained popularity with the rise of Face ID and fingerprint sensors in mobile devices. Biometric data is claimed to be harder to falsify or steal, and offers a level of convenience for endusers.

One-Time Passcodes (OTP) #

OTPs are temporary codes that are delivered to a user’s registered mobile device, typically by SMS, email or push notifications. Users enter the code for authentication, giving a secure and simple way that does not require static passwords.

Hardware Tokens #

Hardware tokens, such as the popular YubiKeys, are physical devices that create authentication codes. Commonly these security token are plugged into a computer via USB or use near-field communication (NFC) for user identity verification. These tokens give an extra degree of security because attackers must physically possess the security token in order gain access.

Software tokens #

Passwordless authentication with software tokens is a popular, adaptable, and cost-effective solution. Software tokens, as opposed to hardware tokens, are digital representations of cryptographic keys that are safely held on a user’s device, such as a smartphone or computer. Users can quickly authenticate themselves by creating and submitting an unique, time-sensitive code via dedicated authenticator apps or a system function.

Magic Links #

Magic links have long been recognized in computer systems as a user-friendly and convenient alternative to other, more elaborate passwordless login techniques. These one-time-only URLs are delivered to a user’s registered email address, allowing them to access a secure service or application with a single click. After clicking the magic link, the user is immediately authenticated and logged into the system without the need for a password.

The Challenges of Passwordless Authentication #

Infrastructure Changes #

To make passwordless authentication work, significant changes to an organization’s existing infrastructure may be required, which can be time-consuming and costly. Distributing hardware tokens to all employees and managing their life-cycle might be a challenge for some organisations.

User Acceptance #

Passwordless authentication requires user acceptance in order to be successful. Some users may be hesitant to adopt new passwordless solutions, especially if they’re not familiar with them or perceive them as less convenient. To steer user adoption, educate your users and staff about the new passwordless system benefits, recommended practices, and support them on any problems they may have.

Passwordless Authentication in Action #

FIDO2 Web Authentication (WebAuthn) #

The FIDO2 Web Authentication (WebAuthn) standard describes a passwordless authentication mechanisms that enable users to access websites and apps using biometrics, mobile devices, or security keys. This standard is supported by major browsers and platforms such as Google, Microsoft, and Apple.

Apple Face ID & Touch ID #

With its Face ID and Touch ID fingerprint scanning technology, Apple has been a pioneer in passwordless authentication. Users can access their mobile devices and authenticate transactions utilizing only their face or fingerprint via these two biometric authentication technologies.

Google Passwordless #

Google has also embraced passwordless implementations, employing a variety of approaches such as biometrics and security keys. Google’s strategy has made it easier for users to gain secure access to their accounts, leading to increasing adoption.

Microsoft Windows Hello #

Microsoft has been among the pioneers in the adoption of passwordless authentication solutions. Users can sign in using Windows Hello, Microsoft Authenticator, or security keys in their implementation. This change has greatly increased security while also streamlining the user experience.

The Rise of Passwordless Authentication Startups #

As passwordless authentication gets more popular, multiple businesses have started to provide novel solutions in this field. Passwordless technology and authentication-as-a-service providers such as HYPR, Trusona, and Beyond Identity assist enterprises in improving their security posture and user experience with off-the-shelf solutions. But also established players such as Okta (Fastpass) and Auth0 provide and implement passwordless authentication solutions as part of their authentication system to their customers.

Passwordless Authentication FAQs #

Is passwordless authentication safe & truly secure? #

Yes, passwordless authentication is more secure than traditional password-based techniques and password management in general. It decreases the risk of unwantedly granted access by eliminating the usage of weak or reused passwords. No stolen passwords and no lost or stolen credentials anymore! The overall security depends on the private keys being securely stored.

How can I implement passwordless authentication in my organization? #

To enable passwordless authentication, select a suitable solution (biometrics, OTP, etc.) and perform the necessary infrastructure adjustments. It is also critical to educate users on the new authentication system and its advantages.

Can I still use two-factor authentication (2FA) with passwordless authentication? #

Absolutely! In fact, passwordless authentication methods can be paired with additional other authentication methods and factors to increase security even further. For example, biometrics combined with a hardware token can be used for multi-factor authentication.

What happens if I lose my hardware token or registered device? #

In such circumstances, having a backup authentication solution in place is critical. To ensure that you don’t lose access to your account, you can set up backup procedures like biometrics, OTP, or even an alternative device or hardware token.

How does passwordless authentication affect user privacy? #

Biometric authentication processes, such as passwordless authentication, can pose privacy concerns. Users may be cautious to submit sensitive information since there is no way to avoid biometric surveillance because, unlike passwords, biometric data cannot be changed. Only recently the Chaos Computer Club (CCC) restored an U.S. military biometrics database from unused former military biometric devices containing fingerprints, iris scans, and photographs of more than 2,600 Afghans and Iraqis.

Are there any drawbacks to passwordless authentication? #

While implementing passwordless authentication has numerous advantages, it can come with certain drawbacks, such as required investment in infrastructure and user acceptance. However, the benefits of better security and user experience frequently outweigh the disadvantages.

Passkeys: The Future of Passwordless Authentication #

Passwordless authentication is clearly the way forward as technology progresses and security concerns about data breaches grow. We can anticipate big improvements in online security, access management and user experience as more organizations adopt this method. One of these innovations are passkeys!

Passkeys are gaining the attention of both consumers and security experts in the quickly evolving world of passwordless authentication. By seamlessly merging the greatest parts of existing passwordless authentication mechanisms, this cutting-edge technology promises to transform online security and user experience. I recently wrote about the Passkey controversies, make sure to read!

What are Passkeys? #

Passkeys are digital credentials enabling a novel kind of passwordless login based on FIDO protocols that combines the ease of use of one-time passcodes (OTPs) with the security of cryptographic keys. Unlike traditional OTPs, which are often provided via SMS or email and are vulnerable to interception, passkeys produce unique, time-sensitive codes using standard public key cryptography techniques.

During online service sign-up, the user’s client device generates a new cryptographic public private key pair. The user’s private key is kept and securely stored within the device, while the corresponding public key, is registered with the online service. The client device authenticates itself by signing a authentication challenge which then is verified using the public key, thus proving possession of the private key to the service. In this way, a passkey can replace password-based authentication and a second factor in a single step.

Microsoft, Apple, and Google have all updated their operating systems and apps to include passkeys in recent months and are focussed on finally killing passwords.

Conclusion #

Passwordless authentication is an effective answer to today’s cybersecurity challenges. It provides a more secure and user-friendly experience for users while lowering support costs for enterprises by eliminating the dependency on passwords. As more businesses decide to go with a passwordless authentication solution, the digital world will become brighter and more secure. Go and setup your passkeys now!

Do login challenges and risk scoring stop account takeover?

Thu, 27 Apr 2023 00:00:00 +0200

Latest change (2026-10-13): Rewritten as a field-guide entry: question title, short answer, key findings and evidence table. Study summaries kept and extended with numbers from the papers.

Short answer: They are an important barrier if you pick the right challenge: device-based challenges blocked over 94% of phishing-rooted hijacking attempts at Google, while knowledge-based challenges stopped as few as 10%. The cost is friction, as 52% of legitimate users who got a challenge failed to sign in at first.

Key findings #

Device-based login challenges blocked over 94% of hijacking attempts rooted in phishing and 100% of automated hijacking attempts.

Source: Doerfler et al., Evaluating Login Challenges as a Defense Against Account Takeover (WWW 2019)

Link to this finding Save as image (PNG, 1200 by 630 pixels)

Login challenges caused 52% of legitimate users to fail to sign in, although 97% got into their account within a short period.

Source: Doerfler et al., Evaluating Login Challenges as a Defense Against Account Takeover (WWW 2019)

Link to this finding Save as image (PNG, 1200 by 630 pixels)

A statistical login classifier using IP and user-agent history reached a recall of up to 89% at a 10% false-positive rate on LinkedIn login data.

Source: Freeman et al., Who Are You? A Statistical Approach to Measuring User Authenticity (NDSS 2016)

Link to this finding Save as image (PNG, 1200 by 630 pixels)

If you can implement only one defence against online guessing, protect users whose passwords attackers guess frequently more aggressively than others.

Source: Tian, Herley and Schechter, StopGuessing: Using Guessed Passwords to Thwart Online Guessing

Link to this finding Save as image (PNG, 1200 by 630 pixels)

Evidence #

Reinforced authentication studies
Study	Year	Sample	Method	Finding
Evaluating Login Challenges as a Defense Against Account TakeoverGoogle, New York University	2019	Over 350,000 hijacking attempts; 1.2 million legitimate users	Case study of 14 challenge types at Google	Device-based challenges work best; 52% of legitimate users failed at first.
StopGuessing: Using Guessed Passwords to Thwart Online GuessingCarnegie Mellon University, Microsoft Research	n/a	n/a	Open-source implementation and attack simulations	Penalize failures with frequently guessed passwords and forgive typos.
Who Are You? A Statistical Approach to Measuring User AuthenticityLinkedIn, Ruhr-Universität Bochum, Università di Cagliari	2016	LinkedIn login data and simulated attacks	Statistical classifier, prototype evaluation	Recall of up to 89% at a 10% false-positive rate.
Distinguishing Attacks from Legitimate Traffic at an Authentication ServerMicrosoft Research	n/a	n/a	Statistical estimation with sensitivity analysis	Estimating the bad-to-good traffic ratio avoids fixed lockout thresholds.

What to do #

For engineers #

Score every login on signals the user doesn’t type, such as IP address history, device and browser. Freeman et al. reached a recall of up to 89% using IP and user-agent history.
Prefer device-based challenges, such as a prompt on a known device, over knowledge questions. Doerfler et al. measured a large gap between the two. My essay on step-up authentication shows how to request a stronger factor only when the risk justifies it.
Count failed logins by how likely they are to be an attack. Penalize failures with frequently guessed passwords, protect accounts with weak passwords harder, and be lenient with typos. Tian et al. do this without storing anything that would expose accounts if leaked.
Breadth-first guessing spreads attempts thinly over many accounts, so per-account lockouts don’t see it. Herley and Schechter estimate the share of attack traffic instead of relying on fixed thresholds. See password spraying and honeytokens for related detection.

For product and UX #

Budget for friction. A challenge that half of your legitimate users fail at first needs a clear path back in, or it turns into support tickets and lost users.
Challenge only suspicious logins, so most users never see a challenge. The 2 risk-scoring studies above show how to pick them out.

The studies in detail #

Google and New York University teamed up to “study the efficacy of login challenges at preventing account takeover” and to “evaluate the amount of friction these challenges create for normal users”. Using Google as a case study, they evaluated 14 device-based, delegation-based, knowledge-based and resource-based challenges against over 350,000 real-world hijacking attempts, and measured usability on a sample of 1.2 million legitimate users.

Device-based challenges blocked over 94% of phishing-rooted attempts and all automated ones. Knowledge-based challenges stopped as few as 10% of phishing-rooted attempts and 73% of automated ones. The conclusion is sobering:

“Our results illustrate that login challenges act as an important barrier to hijacking, but that friction in the process leads to 52% of legitimate users failing to sign-in—though 97% of users eventually access their account in a short period.”

Read the paper (PDF)

Using Guessed Passwords to Thwart Online Guessing #

This paper from Microsoft Research and Carnegie Mellon University gives practitioners who defend password-protected resources against online guessing a set of techniques to better balance friction and security:

“Among our contributions are features to make better benign/attack traffic classification decisions. These include mechanisms to penalize fail events with commonly guessed passwords more, to protect accounts with weak passwords better, and to distinguish user-generated typos from other fails. We do all of these without storing any information which exposes accounts to new risk in the event of a server breach. These innovations allow much greater flexibility over the previous state-of-the-art, which treats all failures equally”

The authors publish an open-source implementation and a guessing-attack simulator. If practitioners can implement only one of the techniques, they recommend protecting users who rely on frequently guessed passwords more aggressively.

Read the paper (PDF)

A Statistical Approach to Measuring User Authenticity #

Researchers from LinkedIn, Ruhr-Universität Bochum and Università di Cagliari evaluated a statistical framework for “strengthening password-based authentication by classifying login attempts into normal and suspicious activity based on parameters available during login”. Suspicious attempts can then get an extra verification step, such as a phone-based one.

They tested the approach on real-life login data from LinkedIn and on simulated attacks. Using the user’s IP history and user-agent history, it showed a “recall of up to 89% for a false-positive rate of 10%”.

Read the paper (PDF)

Distinguishing Attacks from Legitimate Traffic at an Authentication Server #

In this paper, Microsoft researchers look at how to defend against breadth-first attacks that spread guesses very widely. Lockout rules such as “three strikes” work against attacks on one account, but at large providers breadth-first attacks can send millions of guesses without triggering them. The authors describe “a simple robust procedure to estimate the ratio of bad-to-good traffic and show how this can be used to calculate the likelihood that any particular observation is indicative of malice.”

They conclude that their “approach has the advantage over three strikes type lockout and variants that it has no dependence on arbitrary thresholds and we avoid base rate neglect. It has the advantages over machine learning schemes that it requires no labels, and does not assume stationarity of attack traffic.”

Read the paper (PDF)

How secure are email-based password resets?

Fri, 21 Apr 2023 00:00:00 +0200

Latest change (2026-10-13): Rewritten as a field-guide entry: question title, short answer, key findings and evidence table. Study summary kept and extended with the paper’s measured results.

Short answer: In a 2021 study of 366 websites from the Alexa Top 5K, 72% of account recovery mechanisms had at least one implementation weakness. Common gaps were multiple valid reset tokens, missing change notifications and long-lived reset links.

Key findings #

In a study of 366 popular websites, 72% of account recovery mechanisms had at least one implementation weakness.

Source: Innocenti et al., You've Got (a Reset) Mail (DIMVA 2021)

Link to this finding Save as image (PNG, 1200 by 630 pixels)

40% of the websites studied generated multiple valid password reset tokens at the same time.

Source: Innocenti et al., You've Got (a Reset) Mail (DIMVA 2021)

Link to this finding Save as image (PNG, 1200 by 630 pixels)

45% of the websites studied did not notify the account owner after a password change, so an unauthorised reset went unnoticed.

Source: Innocenti et al., You've Got (a Reset) Mail (DIMVA 2021)

Link to this finding Save as image (PNG, 1200 by 630 pixels)

Only 13% of the websites studied followed the OWASP guidelines for password reset.

Source: Innocenti et al., You've Got (a Reset) Mail (DIMVA 2021)

Link to this finding Save as image (PNG, 1200 by 630 pixels)

Evidence #

Account recovery studies
Study	Year	Sample	Method	Finding
You've Got (a Reset) Mail: A Security Analysis of Email-Based Password Reset ProceduresNortheastern University, University of Trento, KU Leuven, Florida International University	2021	366 websites from the Alexa Top 5K	Manual registration and semi-automated checks against 8 OWASP-based controls	72% had at least one weakness; only 13% followed the OWASP guidelines.

What to do #

For engineers #

The weaknesses Innocenti et al. measured map to concrete controls:

Keep one valid reset token per account. Invalidate older tokens when a user requests a new one, and accept each token only once.
Give reset links a short expiry. The study counted any link still valid after 24 hours as a weakness, and found that in 75 websites.
Send reset links over HTTPS only. 52 websites sent tokens in insecure links.
End existing sessions after a reset. 38% of the websites kept them alive.
Protect the flow against login CSRF and header manipulation. Build reset links from configuration, not from the request’s host header.

Treat recovery as a high-risk action that deserves the same scrutiny as login. Step-up authentication shows how to require more proof for sensitive actions.

For product and UX #

Notify the account owner after every password change, and include a way to report “this wasn’t me”.
Keep the reset email plain and predictable, so users can spot a fake one.
Recovery is also an account takeover path. The account hijacking entry covers attacks that start before sign-up.

The studies in detail #

Security Analysis of Email-Based Password Reset Procedures #

An international group of researchers from the USA, Italy and Belgium analyzed the email-based account recovery mechanisms of websites in the Alexa Top 5K. They manually registered accounts and triggered password recovery on sites from 3 popularity groups, ending up with 366 websites. They checked each site against 8 implementation controls derived from the OWASP guidelines.

The paper describes a heterogeneous reality. 72% of the websites had at least one weakness, and only 13% followed the OWASP guidelines. 40% generated multiple valid tokens, 45% sent no notification after a password change, and 22% were vulnerable to login CSRF. The authors also outline concrete password-recovery attacks that can lead to account takeover.

“We hope that this paper will pave the way in highlighting the importance of improving the email-based account recovery mechanisms in real-world websites.”

Read the paper (PDF)

How do attackers take over accounts?

Fri, 21 Apr 2023 00:00:00 +0200

Latest change (2026-10-13): Rewritten as a field-guide entry: question title, short answer, key findings and evidence table. Study summaries kept and extended with numbers from the papers.

Short answer: Some attackers prepare an account before the victim even signs up: at least 35 of 75 popular services studied were vulnerable to such pre-hijacking. Others are paid to break into a specific account and mostly use tailored phishing that can get past SMS two-factor authentication.

Key findings #

At least 35 of 75 popular online services were vulnerable to one or more account pre-hijacking attacks.

Source: Sudhodanan and Paverd, Pre-hijacked accounts (USENIX Security 2022)

Link to this finding Save as image (PNG, 1200 by 630 pixels)

In an account pre-hijacking attack, an attacker who knows only the victim’s email address acts before the victim creates an account and gains access after the victim has signed up.

Source: Sudhodanan and Paverd, Pre-hijacked accounts (USENIX Security 2022)

Link to this finding Save as image (PNG, 1200 by 630 pixels)

Of 27 hack-for-hire services that researchers approached as buyers, only 5 succeeded in attacking the email accounts of the test identities.

Source: Mirian et al., Hack for Hire (WWW 2019)

Link to this finding Save as image (PNG, 1200 by 630 pixels)

Hack-for-hire attackers relied mainly on tailored phishing messages that were sophisticated enough to bypass SMS two-factor authentication.

Source: Mirian et al., Hack for Hire (WWW 2019)

Link to this finding Save as image (PNG, 1200 by 630 pixels)

Evidence #

Account hijacking studies
Study	Year	Sample	Method	Finding
Pre-hijacked accounts: An Empirical Study of Security Failures in User Account Creation on the WebIndependent researcher, Microsoft Security Response Center	2022	75 popular online services	Attack design and testing against live services	At least 35 services were vulnerable to one or more of 5 pre-hijacking attacks.
Hack for Hire: Exploring the Emerging Market for Account HijackingUC San Diego, Google	2019	27 English, Russian and Chinese hack-for-hire services	Posing as buyers against synthetic victim identities	5 services succeeded, mostly through tailored phishing.

What to do #

For engineers #

Don’t let anyone use an account before they have proven they control its identifier. Verify the email address before the account becomes usable, and before you merge a password account with a federated login for the same address.
Only trust email addresses from identity providers that verify them. One of the 5 attacks relies on a non-verifying identity provider.
End all sessions and expire pending email-change links when the password is reset or the email address changes. Two of the attacks rely on unexpired sessions and email changes.
Offer phishing-resistant factors. The hack-for-hire services got past SMS codes with phishing. See passwordless authentication and my critical notes on passkeys.

For product and UX #

Show users which sign-in methods are linked to their account, and notify them when one is added.
When someone signs up with an address that already has a pending or unverified account, guide them through verification instead of silently signing them in.
Recovery flows are another takeover path. The account recovery entry lists the common weaknesses.

The studies in detail #

Account Pre-Hijacking Attacks: Security Failures in User Account Creation #

“The ubiquity of user accounts in websites and online services makes account hijacking a serious security concern. Although previous research has studied various techniques through which an attacker can gain access to a victim’s account, relatively little attention has been directed towards the process of account creation.”

In this study, Avinash Sudhodanan and Andrew Paverd show that there is a whole class of account pre-hijacking attacks. The key point: “The distinctive feature of these attacks is that the attacker performs some action before the victim creates an account, which makes it trivial for the attacker to gain access after the victim has created/recovered the account.”

The authors assume a realistic attacker who knows only the victim’s email address. They describe 5 attacks: Classic-Federated Merge, Unexpired Session, Trojan Identifier, Unexpired Email Change and Non-verifying IdP. Of 75 popular services they analyzed, at least 35 were vulnerable to one or more of them. Some attacks were completely undetectable from the victim’s point of view. The paper closes with security requirements that prevent these vulnerabilities.

Read the paper (PDF)

Hack for Hire: Exploring the Emerging Market for Account Hijacking #

In this paper, researchers from UC San Diego and Google “study a segment of targeted attackers known as ‘hack for hire’ services to understand the playbook that attackers use to gain access to victim accounts.”

Posing as buyers, they contacted 27 English, Russian and Chinese black-market services, and only 5 succeeded in attacking the synthetic but realistic identities the researchers controlled. The attackers mostly used tailored phishing that could bypass SMS two-factor authentication. The authors also observed low volume, poor customer service and multiple scammers in this market. The paper is a good read if you want to understand the commercial account hijacking ecosystem and the techniques criminals use.

Read the paper (PDF)

About Jan Brennenstuhl

Thu, 08 Apr 2021 00:00:00 +0200

Hi. My name is Jan Brennenstuhl, I live and work in Berlin Germany, where I was born and raised. I am a product-minded software engineer, security enthusiast & clean code artist with a huge interest in interdisciplinary software development and engineering leadership. I am a big fan of cycling sports, coffee & hiking.

I currently work in Berlin as principal engineer, focused on application security and making agentic engineering more secure and efficient. I spent years building and operating identity solutions used by millions of customers — balancing UX and security in high-stakes revenue funnels — and have since moved into the broader AppSec space, where I’m most interested in the intersection of security, usability, and automation.

I’ve worked as software engineer and lead on e-commerce funnels, rule engines, cloud strategies, IAM and SSO solutions, REST APIs, system integrations, technology research, legacy migrations, decommissioning projects and modularizing monolithic systems — various things, mostly in e-commerce and security. I practiced software archaeology more than I set up greenfield web services.

I am an internet standards enthusiast, who values open source software and open formats over custom builds. For me, quality software products are created best by small teams of product-minded engineers with a narrow, well-defined business scope and a clear vision. I’m especially passionate about leading and influencing engineers as well as creating and operating reliable, secure and maintainable software products.

I hold a M.Sc. in Computer Science from the University of Potsdam, where I completed my thesis on “Certificate Management in the Cloud for Authentication in university Environment”. I’ve also studied Media Informatics at the Beuth University of Applied Sciences in Berlin.

The Purpose of JWT: Stateless Authentication

Fri, 28 Apr 2017 00:00:00 +0200

The demand for reliable and effective authentication methods has increased in the modern, distributed, and fast-paced digital world. Stateless authentication solutions are being used by developers and identity providers to deliver secure and scalable single sign-on solutions. JSON Web Token (JWT) are the new fancy kids around the block when it comes to transporting proofs of identity within an untrusted environment like the web.

Stateless Sessions Thanks to JSON Web Token #

While there are many articles that describe specific aspects, best practices or single use-cases of JWTs, the bigger picture and the actual problem definition is often missing. With JWTs gaining in popularity, that missing knowledge of the fundamental ideas of JSON Web Token leads to questions:

In this article, I describe the true purpose of JWT tokens – Getting rid of stateful authentication! – and compare classical, stateful sessions with modern, stateless authentication. Let’s start now!

What is JWT? #

Definition #

JSON Web Tokens are a self-contained, URL-safe way of conveying data, unique identifier and claims between two parties in an untrusted environment. They are frequently employed in online applications for the purposes of authentication and authorization of users, transporting proof of authenticity between an identity provider and relying parties.

Components of JWT tokens #

JWTs carry claims that are encoded as JSON object as the payload of a JSON Web Signature (JWS) structure or of a [JSON Web Encryption (JWE)] (https://www.janbrennenstuhl.eu/jwe/ “JWE Token: A Comprehensive Guide”) structure, allowing the claims to be encrypted and/or digitally signed in order to protect their integrity. A signed JWT is made up of three components: a header, a payload, and a signature. The header contains metadata, like the type of token and signing algorithm. The claims are stored in the payload and hold details about the particular user and other necessary data. Finally, the signature is used to affirm the token’s integrity.

Parts of a signed JWT

The Need for Stateless Authentication #

Stateless authentication is essential for modern web applications because it eliminates the need for the central authentication server to retain session id and session information. Ideally, this minimizes backend load and enables more effective application scaling. By removing bottlenecks, a decentralized authorization approach is said to simplify system landscape.

Stateful Authentication #

In the old days of the web, authentication was a purely stateful affair. With a centralized overlord entity being responsible for tokens, the world is fairly simple:

Tokens are issued and stored as stateful session data in a single service for future checking and revocation.
Clients and resource servers know a single point of truth for token verification and information gathering.

This works rather well in a world of integrated systems, where servers render frontends and dependencies exist on package-level rather than distributed applications.

In a world where applications are composed by a zoo of microservices however, this stateful authentication approach comes with a couple of serious drawbacks:

No service can operate without a synchronous dependency towards the central token store.
The token overlord, storing session data, becomes an infrastructural bottleneck and a single point of failure.

Both facts oppose the fundamental ideas of a stateless services landscape. Stateful authentication introduces not just another dependency for all your single-purpose services (network latency!) but also makes them heavily rely on access to it. Without the full session information and data database being available, authorization decisions can’t be taken anymore and everything is doomed.

Stateless Authentication #

Stateless token-based authentication describes a system or process, that enables its components to decentrally verify and introspect tokens. This ability to delegate session token verification allows to (partially) get rid of the direct coupling to a central session data database and in that way enables state transfer for authentication proves. The benefits are clear:

Less latency through service-local, decentralized token verification and authorization decisions.
Increased resilience through less network overhead.

Stateless authentication is also able to absolve you from the need to keep track of issued tokens and for that reason removes state (and hence reduces storage) dependencies from your system. The antiquated, heavy-weighted token overlord solution converges to to yet another microservice being mainly responsible for authentication and token issuing.

Stateful vs. Stateless #

Today, an authentication system has to support stateless architecture service landscapes mainly characterized by fleets of thousands of services and millions of actors. Central bottlenecks by design become an operational burden. However there are no silver bullets, JWTs ain’t Swiss army knifes and also stateful authentication has its righteous place.

If you really need a central authentication system to persist session data or if you simply don’t trust people or library source code to correctly verify session information in your JWTs, a stateful overlord approach is still the way to go and there is nothing wrong about it.

The World becomes Stateless - Google Trends

How JWT Enables Stateless Authentication #

Token-based authentication #

Stateless authentication get enabled through the use of stateless tokens (JWT). The authentication server generates these token, which are self-contained and carry all necessary details about the session and the user. In order to avoid the backend from having to keep track of any session ID and session data, the client stores this token and includes it in subsequent requests.

JSON Web Signature (JWS) #

To guarantee the authenticity and integrity of the token, JWT session token must always use JWS. Because the private key material used to create this digital signature is only known to the server, it prevents unauthorized modification of the token.

Pros and Cons of Stateless Authentication with JWT #

Advantages #

Scalability: Stateless authentication removes architectural bottlenecks, can reduce server load and allows for easier horizontal scaling.
Performance: Less server overhead means faster response times.
Simplified architecture: No need to manage sessions stored server-side.

Disadvantages #

Token size: Due to their metadata overhead, JWTs are generally larger than traditional session cookies, increasing bandwidth usage.
Token theft: If a token is stolen, it can be used until it expires, posing a security risk.

Understanding JWT Workflow #

One popular way to achieve stateless authentication is defined in RFC 7523 and leverages the OAuth 2.0 Authorization Framework (RFC 6749) by combining it with signed JWT (RFC 7519, RFC 7515). Instead of storing the token-to-principal relationship in a database in a stateful manner, cryptographic signatures allow decentralized clients to securely store and grant access, without need to retrieve data from a central system for every inbound request.

Stateless tokens are also a key component of OpenID Connect (OIDC), an identity layer solution built on top of the OAuth 2.0 protocol. OpenID Connect specifies industry-standard flows that allow clients to access basic profile information about the end-user in an interoperable way and to confirm the end-user’s identity based on the authentication carried out by an authorization server.

“Using a JWT as a bearer for authorization, you can statelessly verify if the user is authenticated by simply checking if the expiration in the payload hasn’t expired and if the signature is valid.” — Jonatan Nilsson

With tokens not being opaque but locally introspectable, clients can retrieve addition information about the corresponding identity directly from the token without the need of calling another remote API. The following is a simplified, non-normative lifecycle example of a stateless JWT.

Token Creation #

The user submits their credentials (e.g., username and password) to the authentication system.
The server authenticates the actor by verifying the credentials and generates a JWT containing user-related claims.
The server signs the token using a private key and returns it to the client side.

Token Verification #

The client includes the JWT as bearer token within the Authorization header in subsequent requests.
The resource server verifies the token’s signature and validates the claims.
If the token is valid and authorization successful, the resource server processes the request and returns the appropriate response.

Token Expiration #

JWTs typically include an expiration time to limit their validity.
Once the token expires, the client must request a new token by re-authenticating with the authorization server.

Use Cases for JWT #

Authorization: Securely authorize actors based on user claims like roles and permissions without relying on server-side sessions.
Information Exchange: Securely transmit information between parties in untrusted environments.

Security Concerns & Considerations #

Token storage: Store tokens in a secure location on the client side, such HttpOnly cookies or other safe places.
Transport security: Use HTTPS to protect tokens from being intercepted during transmission.
Token revocation: By design, JWTs are not remotely revokable. To revoke tokens in case of token theft or user logout requires, a stateful mechanism to be in place – which sort of counters the stateless approach.
Token update: There is no way of altering an issued JWT. Prolongating its expiration date for example is not possible.

Best Practices for JWT Implementation #

Use short expiration times: Limit the window of opportunity for token theft.
Rotate private keys: Regularly update the signing key to mitigate risks associated with key compromise.
Validate tokens: Before processing requests, always check the tokens validity on the authorizing backend.

Conclusion #

In modern web applications, JWTs offer a reliable and adaptable stateless authentication method. Developers may create secure, scalable, and effective apps that satisfy the requirements of today’s digital ecosystem by utilizing their advantages and following best practices.

FAQs #

What is the main purpose of using JWT in stateless authentication? #

The major goal is enhanced scalability and performance by securely authorizing users without relying on server-side sessions.

How can I prevent JWT theft? #

Tokens must be stored securely on the client side and transmitted encrypted using HTTPS. If stateful revocation procedures are not implemented, tokens should have a short expiration time.

Can I use JWT for authorization as well as authentication? #

JWTs can function as bearer tokens. Authorization decisions can be made either purely on token validity or take into consideration claims carried by the token.

Do I need to store JWT session data in a database? #

No, JWTs are self-contained and do not require server-side storage. Actually that would be an anti-pattern.

How do I handle JWT expiration? #

Implement a mechanism for clients to request a new token when the existing one expires. OAuth 2.0 for example distinguishes between access token and refresh token and defines protocols on how to continuously refresh tokens without need to actively re-authenticate the user.

On Making Spring Security OAuth RFC-compliant

Wed, 01 Feb 2017 00:00:00 +0100

Often supporting open source software is just fixing one tiny thing you stumbled upon. However, getting ready and diving into even the smallest piece of source-code can lead to surprising results. I fixed a small HTTP header extractor for the Spring Security OAuth project recently. Here’s what happened.

I fixed something for me #

At the very least, fixing this issue has made me happier. The problem was that the Spring Security OAuth BearerTokenExtractor was not acting in compliance to RFC7230.

Every time someone sends a request with multiple, comma-separated Authorization-Header values towards an application I am currently developing the extractor would fail in doing its job. The application would simply not accept the yet valid (and RFC compliant) request.

RFC7230, Section 3.2.2 - A sender MUST NOT generate multiple header fields with the same field name in a message unless either the entire field value for that header field is defined as a comma-separated list [i.e., #(values)] …

I fixed something for someone else #

This is a guess, but if I found this an issue then we can presume at least one other person out there on the internet did. Also, being RFC-compliant usually is a good thing and every library should handle user-generated input as resilient as possible.

I learned more about Library Maintenance #

I started by making a mistake. My original fix was a custom implementation of the TokenExtractor interface that is also implemented by the original BearerTokenExtractor within my application. This however would require me to maintain and test this piece of code that is not part of my actual business logic. I would totally loose the advantages of abstraction through a battle-proven library. It also ignored the problems true essence.

That thought lead me to try again. This time I cloned the Spring Security OAuth project and tried copy-and-pasting my slim Java8 Streams API based TokenExtractor and its tests into the library. This lead to a bunch of discoveries about library maintenance — Spring Security OAuth…

… is written in Java6,
… has only other Spring projects as dependencies,
… needs to be backward compatible.

So, if you plan to support a project that is out there for a while, keep in mind to leave all your fancy tooling at home. Also try to read and follow the projects code and style guidelines before receiving requests for change in your pull-requests.

Of course, as with anything around the globe, there is even more to this than meet the eye. However, this was my resulting pull request ~~and it is waiting to get merged~~.

I learned more about HTTP Headers #

In the beginning, I learned about the diversity of HTTP Headers. Being spoiled by all these framework abstraction layers nowadays, it hit me that HTTP Headers are simply yet another interface. And we want to handle all interface interaction in the most resilient way.

Inspired by some of my colleagues, I started to delve into RFCs. I started with RFC6750 (describing the Bearer Token Usage within OAuth 2.0) and ended up in the even more fundamental RFC7230 (on Message Syntax and Routing of the Hypertext Transfer Protocol).

Now I am more familiar with the possible appearances of HTTP Headers and the work behind the Spring Security OAuth project.

~~With my fix in one of the next releases, Spring Security OAuth is going to also be able to handle requests like this:~~

GET /presence/alice HTTP/1.1
Host: server.example.com
Authorization: Basic YXNkZnNhZGZzYWRmOlZLdDVOMVhk, Bearer mF_9.B5f-4.1JqM

Update 16.02.2017: As Joe Grandja (Spring Security Engineer) argued, the user agent is supposed to choose “only 1 of the challenges (if there is more than 1 challenge) to authenticate against”, so my pull request was rejected. Feel free to read all the comments in the corresponding issue for all the details.

The simplest piece of work can lead you anywhere #

I just wanted to make the Bearer Token extraction more resilient. Yet, this lead to a ticket and a pull request, a rabbit hole of discovery about HTTP Headers and open source library maintenance and the motivation to write a blog post about it. Ultimately, I did get what I wanted in the first place though: More fun during work.

Open source is a lot of things to a lot of people. To me, it’s a way to learn while I help, however small the task may seem. I’d love for you to share with me on Twitter what open source means to you.

This post was heavily inspired by Phil Nash.

Identity & Auth · Brennenstuhl on Security

How does authorization work for MCP servers?

Key findings #

Evidence #

What to do #

For engineers #

For product and UX #

How it works #

Related #

How should people grant and revoke an agent's access?

Key findings #

Evidence #

What to do #

For engineers #

For product and UX #

How it works #

Related #

How does OAuth 2.0 Token Exchange keep provider tokens away from agents?

Key findings #

Evidence #

What to do #

For engineers #

For product and UX #

How it works #

Step through the exchange

Related #

What is inside a JWT?

Key findings #

Evidence #

What to do #

For engineers #

For product and UX #

Try it #

Decode a token in your browser

How the parts fit together #

Related #

Should an agent use a robot account or delegated access?

Key findings #

Evidence #

What to do #

For engineers #

For product and UX #

How it works #

Related #

Economies of Scale for MCP and Agents

Materials #

Reading companion #

Agentic Identity Broker

Explore the project #

Mastering JWKS: JSON Web Key Sets Explained

TL;DR #

Technical Specifications of JWK and JWKS #

What is JSON Web Key (JWK)? #

What is JSON Web Key Set (JWKS)? #

Locate JSON Web Key Sets #

Benefits of Using JWKS #

Easy Management of Keys with JWK Sets #

Simplified Key Rotation Process Using JWKs #

Compatibility with Various Protocols and Applications #

Best Practices & Security Considerations #

Use Transport Layer Security #

Make sure JWKS is correct and current #

Validate the signatures of incoming JWTs using JWKs #

Consider rotating your JWKS keys periodically #

Conclusion: The Importance of Using JSON Web Key Sets #

JSON Web Encryption: Exploring JWE Token

TL;DR #

JSON Web Encryption (JWE) Token: A Comprehensive Guide #

The Structure of an Encrypted JWT #

Support for Symmetric and Asymmetric Encryption Algorithms #

Nested JWTs #

Working with Different JWE Algorithms #

JWE with AES Algorithms #

JWE with RSA Algorithms #

JWE with Elliptic Curve Algorithms #

Authenticated Encryption Algorithms #

JWE Token Generation Process #

Encryption Algorithm: Choosing the Right One for Your Needs #

Generating Keys: Private Key vs Secret Key #

Complete JOSE Header #