Initial curated ITWorx_MCP_Hub source from 368fba691ea8d23403b4d56b53b5ec670d7c5020

This commit is contained in:
Public Source Publisher committed 2026-10-01 01:36:21 +02:00
commit cb5be898ea
663 files changed
+82674

No files matched your search

@@ -0,0 +1,55 @@
# ChatGPT OAuth connection persistence
The public MCP endpoint is expected to remain connected in ChatGPT without periodic interactive re-authorization while the OAuth grant remains valid.
## Required provider contract
The Authentik OAuth2/OIDC provider used by the ChatGPT MCP app must expose the `offline_access` scope mapping in addition to `openid`, `profile`, and `email`. This lets a compliant OAuth client request a refresh token instead of depending only on the original access token.
Production configuration therefore requires:
```text
AUTHENTIK_SCOPES=openid,profile,email,groups,offline_access
```
`groups` remains required by the Hub's existing role mapping. The ChatGPT
provider itself uses `openid profile email offline_access`. The public
protected-resource metadata and the MCP `401 WWW-Authenticate` challenge must
advertise that same refresh-capable scope set. `promotion_preflight.py` fails
closed when either `openid` or `offline_access` is absent.
## Authentik one-time reconciliation
In the Authentik admin interface, open the OAuth2/OIDC provider backing the
ChatGPT application (`Provider for ChatGPT - ITWorx Gitea` in production) and
include the built-in `offline_access` scope mapping under Scope mappings. This
is distinct from the browser-facing Hub provider. Keep the authorization-code
flow enabled and keep refresh-token support enabled. Do not weaken redirect
URI, PKCE, audience, or group restrictions to obtain persistence.
After changing the provider, verify its OpenID discovery metadata advertises `offline_access` in `scopes_supported` and verify an authorization requesting that scope receives a refresh token.
Run production preflight with `--verify-oidc-discovery`. This checks both the
browser-facing Hub issuer and the ChatGPT issuer for an exact issuer, HTTPS
authorization/token endpoints, authorization-code and refresh-token grants,
S256 PKCE, and `openid` plus `offline_access` publication.
## Validated production settings
The production ChatGPT provider is confidential and uses one strict
`https://chatgpt.com/connector/oauth/...` redirect. Its access tokens are valid
for five minutes. Refresh tokens are valid for 365 days and the refresh
threshold is `seconds=0`; on the deployed Authentik version this rotates the
refresh token on every successful refresh and revokes the prior token. These
settings preserve short access-token exposure, revocability, and durable
connections without disabling PKCE or widening redirect matching.
## ChatGPT reconciliation
OAuth metadata can be cached at app creation time. After the provider is corrected, recreate or reconnect the ChatGPT MCP app once so ChatGPT reads the updated provider metadata. Thereafter access-token renewal should use the refresh token and should not require routine interactive reconnects.
A future reconnect can still be legitimate after explicit revocation, refresh-token expiry or rotation failure, provider/client reconfiguration, security-policy changes, or deletion/recreation of the ChatGPT app.
## Operational rule
Do not work around reconnect prompts by making access tokens effectively permanent or by replacing user OAuth with a shared long-lived bearer token. Refresh-token based OAuth persistence preserves revocability and the existing identity boundary.