J3-AUTH IDENTITY AUTHORITY
DESIGN PHASE / ARCHITECTURE IN PROGRESS

JARVIS-3 / NEW AUTHORITY

Trust, by design.

J3-AUTH ist die zentrale Identity Authority für die selbst gehostete Infrastruktur: ein klar begrenzter Ort für Identitäten, Sessions, Maschinenzugriffe und delegierte Handlungen. Geplanter Issuer: https://auth.johannesbrunner.de

Human identity — SSO ohne Konto-Wildwuchs Machine identity — kurzlebiger Dienstzugriff Bound permissions — Scope + Ziel + Laufzeit

01 / THE MODEL

One authority. Clear decisions.

01 · Identity

Konten, Service-Identitäten und ihre Lebenszyklen liegen an einer nachvollziehbaren Stelle.

USERS · SERVICES · SESSIONS

02 · Decision

Policies entscheiden über Ziel, Aktion, Laufzeit und Kontext. Standard ist Ablehnung, nicht Vermutung.

POLICY · SCOPES · DENY BY DEFAULT

03 · Proof

Dienste prüfen Berechtigungsnachweise lokal und ohne unnötige Laufzeitabhängigkeit.

SIGNED · BOUND · SHORT-LIVED

02 / FLOWS

Different actors. Same discipline.

Menschen und Dienste brauchen unterschiedliche Einstiege. Die Sicherheitslogik bleibt dieselbe: starke Identität, minimale Rechte, klarer Empfänger.

USER AUTHENTICATION

A person signs in once, not everywhere.

Anwendungen erhalten eine standardisierte OIDC-Integration. Der Auth-Server übernimmt Identität und Session; die Anwendung bleibt für Oberfläche und Fachlogik verantwortlich.

OIDC · PKCE · SSO

SERVICE AUTHENTICATION

A service gets only its window.

Hintergrunddienste authentifizieren sich mit eigener Maschinenidentität. Jeder Token ist an bekannten Dienst, Ziel und definierte Aktionen gebunden.

CLIENT · TTL · AUD

CONTROLLED DELEGATION

A service acts for a person.

Delegation ist ein expliziter, begrenzter Vorgang: der Nutzer bleibt zurechenbar, der handelnde Dienst wird separat ausgewiesen.

SUB · ACT · SICHERE SCHNITTMENGE

03 / TRUST BOUNDARIES

Every proof has an edge.

Ein Dienst akzeptiert keinen beliebigen Nachweis. Diese Grenzen sind fest verdrahtet:

iss

Der Aussteller muss exakt der erwarteten Authority entsprechen.

aud

Ein Token gilt für genau ein registriertes Ziel — nicht für das ganze System.

scope

Nur registrierte, gewährte Rechte. Alles andere wird abgelehnt.

exp

Kurzlebig. Nachweise veralten, Vertrauen wird nicht verliehen, sondern geprüft.

04 / BUILD ORDER

Start narrow. Earn complexity.

Die Plattform entsteht in kontrollierten Schritten. Standards helfen beim Vertrag; sie ersetzen keine Entscheidung über unser eigenes System.

P0–P2 Grundgerüst & Identitäten P3 Login & Code-Flow P4 Tokens & Ziele P5 Delegation P6 Administration P7 Betrieb P8 Verifikation