QDG Identity user guide

Document version: 1.0.1. Updated 6 September 2026. The first release is being verified; 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.

The initial pilot proves the exact client setup before team instructions are declared supported. 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. A permitted active client should renew through Auth0; it may need a fresh sign-in after inactivity or the absolute lifetime. The exact behaviour is part of the real-client proof.

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. 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. Their actual desktop/host procedures remain subject to the live acceptance checks.

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