Skip to content

Latest commit

 

History

History
109 lines (76 loc) · 5.72 KB

File metadata and controls

109 lines (76 loc) · 5.72 KB

Documentation Hub

This is the central navigation for TokenSheriff documentation.

1. Architecture Decisions

Standing architectural decisions, recorded as durable ADRs under doc/adr/.

2. Commons (base layer)

The shared base layer every capability sits on — the de.cuioss.sheriff.token.commons.* packages inside token-sheriff-validation (transport, error model, security events, metrics), enforced by ArchUnit rather than shipped as a separate module.

2.1. Specifications

  • Transport - Discovery, JWKS, token/userinfo/…; TLS, SSRF, resilience

  • Error Model - Typed exceptions → RFC 9457 at every HTTP edge

  • Observability - SecurityEventCounter events + metric identifiers

3. Token Validation

The token validation capability — its requirements, architecture, security model, and specifications.

  • Overview - Capability entry point: intro, scope, reading order, document map

  • Requirements - Functional and non-functional requirements

  • Architecture - Validation pipeline, components, and design

3.1. Security

3.2. Specifications

3.3. FAQ

4. Client

The active OIDC capability — the server-side confidential-client engine that retrieves tokens, holds and refreshes them server-side, and drives the flows on top of the commons transport. It is the engine a Backend-For-Frontend (BFF) is built on; it is not itself a BFF. The token-sheriff-client module (and its token-sheriff-client-quarkus extension) is implemented; this document set remains the normative specification.

  • Overview - Capability entry point: intro, scope, reading order, document map

  • Requirements - CLIENT-N, grouped by aspect (Retrieval & flow / Token)

  • Architecture - Client/BFF engine seam and boundaries

  • References - Bibliography

4.1. Security

4.2. Specifications

5. Reference

6. Module Documentation

8. Configuration