QDG Identity user guide

Document version: 1.0.2. Updated 6 September 2026. Robert's bounded Codex pilot has passed; production OAuth onboarding is not yet complete.

Who this service is for

The first release lets approved users access QDG Knowledge Base through its MCP service. Robert owns access decisions and is the first test user. Codex desktop is the first client to prove. Other MCP clients need their own compatibility checks.

Existing QDBAuth websites continue to use their current login. This project does not migrate them on day one, reuse their passwords or convert their tokens.

What the user experience should be

An approved user adds the supported KB MCP connection in their client and follows the hosted Auth0 sign-in. The client manages the resulting service-specific token. The user should not copy a bearer token into a conversation, documentation or source code.

Robert's hosted Auth0 login and all ten KB tools have passed through the Codex engine and a fresh desktop-attached connection against synthetic data. Current-policy read/write denial, restoration, stale-version protection and continued use beyond the original access-token lifetime also passed. This proves the bounded pilot client; it does not mean that the Odin production service or team onboarding is complete. A dashboard administrator account and an application end-user account are different: being able to administer Auth0 does not itself grant KB access.

Read and write access

Read access permits the existing read-only KB tools. Read and write are separate permissions. The approved writer access bundle explicitly grants both qdg-kb:read and qdg-kb:write; a write-only token does not automatically permit reading. The client token and current approved user rights must both permit each operation.

The KB retains immutable page versions and checks the expected version before an update. A version conflict means the page changed; reread and reconcile the changes before retrying. Identity does not remove this protection.

Login renewal and removal

The pilot uses short access tokens and bounded rotating refresh credentials. Continued authenticated use beyond the original access-token lifetime passed in independent Codex processes. A client may still need a fresh sign-in after inactivity or the absolute refresh lifetime. Approval-screen behaviour and recovery of the earlier retained desktop task remain open observations.

If access is removed, a previously issued token must remain denied by the service's current policy. Repeatedly signing in is not a way around an access decision. Contact the service owner for an entitlement review.

When access fails

• A login prompt normally means the client needs an approved Auth0 session or token.
• Permission denial means the operation or account is not currently allowed.
• Service unavailability may involve Auth0, the MCP host, routing, the database or audit storage.
• A healthy status page alone does not prove an authenticated operation can succeed.

Report the time, client/version, requested operation and safe error text. Do not send passwords, tokens, login codes, private configuration or copied KB content in a diagnostic report.

During an Auth0 outage

Existing normal access may last only while the token and cached signing key remain acceptable. New login and renewal depend on Auth0.

The planned operating exception is an explicitly activated Robert-only read credential with a maximum one-hour lifetime. It is not a general team login method. It remains disabled until its protected host configuration and actual client procedure are tested. Emergency writes are refused, and logging failure or local removal also blocks emergency reads.

Further documentation

How to Use describes the operator workflow and current Odin inspection step. Project Description explains the architecture and reasons for the security choices. The local pilot guide records the engineering setup, while the outage runbook records the recovery controls. Production host, database, ingress, restart and recovery procedures remain subject to live acceptance.

The detailed additional-service integration guide will follow the verified first deployment, so other teams can follow proven instructions.