Adam
/
AyCode.Core
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
AyCode.Core/docs/AUTH
History
Loretta c062ded9a4 [LOADED_DOCS: 3 files, no new loads] 
Update ID format to use per-repo prefixes and random suffix

Migrated all issue, TODO, and decision IDs to a new 4-part format: <PREFIX>-<TOPIC>-<TYPE>-<RAND>. Added per-repo prefix declarations in copilot-instructions.md and documented conventions in REPO_PREFIXES.md. Updated all topic registries, logs, cross-references, and documentation to use the new format. Introduced MIGRATION_ID_MAPPING.md for old-to-new ID mapping. Enhanced skills and protocol audit logic to validate and enforce per-repo prefixes and topic codes at runtime. Clarified Framework-First doctrine and ensured all references are unambiguous.
 		2026-04-26 19:12:50 +02:00
..
AUTH_ISSUES.md [LOADED_DOCS: 3 files, no new loads] 2026-04-26 19:12:50 +02:00
AUTH_TODO.md [LOADED_DOCS: 3 files, no new loads] 2026-04-26 13:44:12 +02:00
README.md [LOADED_DOCS: 3 files, no new loads] 2026-04-26 19:12:50 +02:00

README.md

AUTH — User Authentication

Bearer-token user authentication: JWT issuance, client-side token storage, HTTP + SignalR transport bindings, per-tag SignalR dispatch authorization, and security hardening.

Architectural authority: ../adr/0001-user-bearer-token-flow.md. This README is the consumer-facing recipe; the ADR captures rationale and decision history.

Status

⚠️ Pre-implementation. ADR 0001 specifies the architecture; the framework code has not yet landed. This README is a scaffold — the "Consumer recipe" section is a placeholder for content that fills in as the implementation progresses (per ADR 0001 Follow-up "Implementation" series).

Scope

Concern Decision
Token issuance JWT (HS256, 24h fixed lifetime, configurable per consumer); refresh-flow deferred to ADR 0002
Client-side storage IAcTokenStore framework abstraction; consumer-supplied platform impls (MAUI / WASM)
HTTP transport Framework-provided delegating handler injects bearer header automatically
SignalR transport Framework hub-builder extension wires access-token provider; WASM uses query-string fallback
Server-side validation Standard ASP.NET Core JwtBearer pipeline via framework DI bundle
Per-tag authorization Hub-class [Authorize] default + explicit allowlist attribute for unauth tags (login, ping)
Security hardening Startup options validation (key length, issuer/audience), HTTPS metadata required outside Development

Out of scope (per ADR 0001)

Refresh-token flow (→ ADR 0002), role/claims authorization, multi-tenant claims, OAuth2 / external IdP, token revocation, logout server-side invalidation.

Files in this folder

  • README.md — this file (scope + consumer recipe).
  • AUTH_ISSUES.md — known issues, security observations, edge cases.
  • AUTH_TODO.md — planned work derived from ADR 0001 Follow-ups.

Consumer recipe

Placeholder — populated as implementation progresses.

Sections to come (mirrors ADR 0001 Follow-up "Implementation" + "Consumer wiring"):

  • DI registration bundle examples (MAUI + WASM + Server)
  • IAcTokenStore consumer implementation skeletons
  • Hub allowlist attribute usage
  • appsettings.json AyCode:Jwt section reference
  • HTTPS / Kestrel / proxy notes (especially WASM access_token URL-param redaction)

Security: Never log secrets

JWT signing keys, access tokens, refresh tokens, password hashes, and OAuth client secrets MUST NEVER appear in log output. Logged secrets leak via the same channels as the logs themselves (file system, retention archives, screenshots, bug reports). For diagnostics, log only metadata (user ID, expiry, issuer) or hash prefixes — never the raw value.

This guideline emerged from ACCORE-LOG-I-P5W3 and ACCORE-LOG-I-K1Z7 (both Closed (2026-04-25) via #if DEBUG gating per ADR 0001 pre-flight). A pending TODO (forthcoming entry in LOGGING_TODO.md, no ID assigned yet) proposes adding a generalized framework-level guideline section to LOGGING/README.md; when that lands, it becomes the canonical home and this section trims to a cross-ref.

Cross-references

  • ADR: ../adr/0001-user-bearer-token-flow.md — architectural decision.
  • Topic registry: AUTH row in TOPIC_CODES.md (added in LLMP-DEC-49).
  • Sibling pre-migration: ACCORE-LOG-I-P5W3 / ACCORE-LOG-I-K1Z7 in LOGGING_ISSUES.md — currently homed in LOGGING; ADR 0001 Follow-up "Status migration on AUTH topic creation" lists these as candidates for relocation here as AUTH-I-N with Superseded by cross-refs in LOGGING. Migration NOT yet performed — separate user-approved follow-up.