OIDC endpoints are derived from a Logto-shaped issuer, not from discovery metadata #9

New issue

Open

opened 2026-08-26 04:58:30 +00:00 by jlxq0 · 0 comments

jlxq0 commented

2026-08-26 04:58:30 +00:00

Owner

No requester, no decision. Filed so the gap has a state rather than living in a docstring.

CARDDAV_MCP_AUTHORIZATION_SERVER is treated as a Logto issuer base: the code
derives /auth, /token, /jwks and /me from it directly rather than
fetching the provider's /.well-known/openid-configuration and reading
authorization_endpoint, token_endpoint, jwks_uri and userinfo_endpoint
out of it. Observable on the deployed instance, whose advertised metadata
carries https://login.kampong.social/oidc/jwks and .../oidc/me, both
constructed rather than discovered.

The docs are currently honest about this (README.md:44 says Logto-compatible,
not arbitrary-OIDC compatible, and this PR removed the one line in AGENTS.md
that claimed otherwise), so nothing is mis-advertised today. The gap is that
"bring your own IdP" is a natural thing for someone to expect from a self-hosted
MCP server and it is not what this ships.

Not started, and should not be started off a code read. It changes the
public auth contract in AGENTS.md. Someone has to want it first.

Scope if it is ever taken:

Fetch and cache the issuer's discovery document at startup, failing closed.
Drive all four endpoints from it; keep the derived values only as a fallback
for an issuer that serves no discovery document, or drop them.
Decide what happens when discovery and CARDDAV_MCP_STALWART_AUDIENCE
disagree, since Stalwart's requireAudience already accepts only one
resource indicator.
The docs claim flips in the same change, never before it.

**No requester, no decision. Filed so the gap has a state rather than living in a docstring.** `CARDDAV_MCP_AUTHORIZATION_SERVER` is treated as a Logto issuer base: the code derives `/auth`, `/token`, `/jwks` and `/me` from it directly rather than fetching the provider's `/.well-known/openid-configuration` and reading `authorization_endpoint`, `token_endpoint`, `jwks_uri` and `userinfo_endpoint` out of it. Observable on the deployed instance, whose advertised metadata carries `https://login.kampong.social/oidc/jwks` and `.../oidc/me`, both constructed rather than discovered. The docs are currently honest about this (`README.md:44` says Logto-compatible, not arbitrary-OIDC compatible, and this PR removed the one line in `AGENTS.md` that claimed otherwise), so nothing is mis-advertised today. The gap is that "bring your own IdP" is a natural thing for someone to expect from a self-hosted MCP server and it is not what this ships. **Not started, and should not be started off a code read.** It changes the public auth contract in `AGENTS.md`. Someone has to want it first. Scope if it is ever taken: - Fetch and cache the issuer's discovery document at startup, failing closed. - Drive all four endpoints from it; keep the derived values only as a fallback for an issuer that serves no discovery document, or drop them. - Decide what happens when discovery and `CARDDAV_MCP_STALWART_AUDIENCE` disagree, since Stalwart's `requireAudience` already accepts only one resource indicator. - The docs claim flips in the same change, never before it.

No labels

waiting-on-julian

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

jlxq0/carddav-mcp#9

No description provided.

Rows
Columns