JWT Claims Referenz

Identifiziert die Stelle, die das JWT ausgestellt hat.

Validierung: Exakt mit einem bereits vertrauenswürdigen Issuer der Anwendung vergleichen.

Identifiziert das Subject innerhalb des Namespace des Issuers.

Validierung: Erst nach Issuer-Validierung und nur in dessen Namespace interpretieren.

Identifiziert die vorgesehenen Empfänger des JWT.

Validierung: Die vom Resource Server erwartete Audience muss enthalten sein.

Zeitpunkt, nach dem das JWT nicht mehr akzeptiert werden darf.

Validierung: Nach exp ablehnen; nur eine kleine konfigurierte Clock Tolerance zulassen.

Zeitpunkt, vor dem das JWT nicht akzeptiert werden darf.

Validierung: Vor nbf ablehnen, außer innerhalb der ausdrücklich konfigurierten Clock Tolerance.

Zeitpunkt, zu dem das JWT ausgestellt wurde.

Validierung: Für Age/Lifetime-Policy verwenden und unplausible Zukunftswerte ablehnen.

Eindeutiger Bezeichner für das JWT.

Validierung: Nur mit serverseitigem Zustand kombinieren, wenn Replay-Schutz oder Revocation dies benötigt.

Identifiziert die Partei, für die das ID Token ausgestellt wurde.

Validierung: Bei mehreren Audiences oder entsprechender Client-Policy prüfen.

Bindet ein ID Token an die zugehörige Browser/Client-Anfrage.

Validierung: Exakt mit dem für den Authorization Request gespeicherten Nonce vergleichen.

Zeitpunkt der Endnutzer-Authentifizierung.

Validierung: Nutzen, wenn max_age oder Reauthentication vom Alter der Anmeldung abhängt.

Erreichte Authentication Context Class.

Validierung: Nur Assurance Levels akzeptieren, die die Anwendung ausdrücklich versteht.

Tatsächlich verwendete Authentifizierungsmethoden.

Validierung: Aus unbekannten Werten kein Assurance Level ableiten; Issuer-Semantik beachten.

Hash-abgeleiteter Wert zur Bindung eines Access Tokens an ein ID Token.

Validierung: Validieren, wenn OIDC Flow/Response Type es erfordert.

Hash-abgeleiteter Wert zur Bindung eines Authorization Codes an ein ID Token.

Validierung: Validieren, wenn der OIDC Response Type es erfordert.

Bindet in bestimmten OIDC/FAPI-Profilen state an eine signierte Antwort.

Validierung: Nur validieren, wenn das aktive OIDC/FAPI-Profil es verlangt.

Identifiziert eine Session beim OpenID Provider.

Validierung: Als issuer-gebundene Session-Metadaten behandeln, nicht als globale User-ID.

Vollständiger Anzeigename des Endnutzers.

Validierung: Profilwert; nicht als stabile Autorisierungs-ID verwenden.

Vorname des Endnutzers.

Validierung: Nur für Darstellung verwenden und Lokalisierung berücksichtigen.

Nachname des Endnutzers.

Validierung: Keine Eindeutigkeit annehmen.

Zweiter Vorname des Endnutzers.

Validierung: Als optionalen Profilwert behandeln.

Spitzname des Endnutzers.

Validierung: Nur für Darstellung verwenden.

Bevorzugter kurzer Benutzername.

Validierung: Keine globale Eindeutigkeit oder Unveränderlichkeit annehmen.

URL der Profilseite.

Validierung: URL-Behandlung vor dem Rendern eines Links validieren.

URL des Profilbilds.

Validierung: Beim Rendern als nicht vertrauenswürdigen Remote-Inhalt behandeln.

URL der Website des Endnutzers.

Validierung: Als nicht vertrauenswürdige Profildaten behandeln.

Bevorzugte E-Mail-Adresse.

Validierung: Nur als verifiziert behandeln, wenn email_verified=true und der Issuer vertrauenswürdig ist.

Zeigt an, ob der Issuer die Kontrolle über die E-Mail geprüft hat.

Validierung: Nur mit vertrauenswürdigem Issuer und bekannter Prüfmethodik verwenden.

Vom Issuer bereitgestellte Geschlechtsangabe.

Validierung: Datensparsamkeit beachten, wenn der Wert nicht benötigt wird.

Geburtsdatum des Endnutzers.

Validierung: Sensibler Profilwert; nicht als Authentifizierungsfaktor verwenden.

Zeitzonenkennung des Endnutzers.

Validierung: Nur für Darstellung/Präferenzen verwenden.

Locale-Präferenz des Endnutzers.

Validierung: Für Darstellung nutzen, nicht für Trust Decisions.

Bevorzugte Telefonnummer.

Validierung: Nur als verifiziert behandeln, wenn phone_number_verified=true und der Issuer vertrauenswürdig ist.

Zeigt an, ob der Issuer die Kontrolle über die Nummer geprüft hat.

Validierung: Nach Issuer-Policy und verwendeter Prüfmethodik interpretieren.

Strukturiertes Objekt für die Postadresse.

Validierung: Verschachtelte Felder vor Darstellung prüfen und als sensible Daten behandeln.

Zeitpunkt der letzten Profilaktualisierung.

Validierung: Nur als Metadatum zur Profilaktualität verwenden.

Identifiziert den OAuth Client des Access Tokens.

Validierung: Nur vergleichen, wenn die Resource-Server-Policy einen bestimmten Client verlangt.

Delegierte Berechtigungen des Access Tokens.

Validierung: Nur Scopes autorisieren, die die Ressource versteht und die zur Audience passen.

Rollenwerte für Autorisierungsentscheidungen.

Validierung: Issuer/Resource-Semantik definieren und unbekannte Rollen standardmäßig ablehnen.

Gruppenmitgliedschaften für Autorisierungsentscheidungen.

Validierung: Keine gemeinsame Benennung oder Hierarchie über verschiedene Issuer annehmen.

Entitlements für Rechte oder Berechtigungen.

Validierung: Jedes Entitlement explizit auf erlaubte Aktionen abbilden.

Bestätigungsinformationen für einen Proof-of-Possession-Schlüssel.

Validierung: Die vom Token/Profil geforderte Confirmation-Methode tatsächlich validieren.

Identifiziert den handelnden Akteur bei Delegation oder Impersonation.

Validierung: Actor und Subject in Autorisierung und Audit getrennt behandeln.

Identifiziert Parteien, die für das Subject handeln dürfen.

Validierung: Nur in Token-Exchange-Designs mit expliziter Delegation-Policy verwenden.

Private Liste erlaubter Anwendungsaktionen.

Validierung: Issuer, Audience und Permission-Semantik dieser privaten Claims klar definieren.

Private Konvention für eine oder mehrere Rollen.

Validierung: Nicht automatisch mit roles gleichsetzen; pro Issuer abbilden.

Private Konvention für Tenant- oder Organisationsrouting.

Validierung: Tenant allein begründet kein Issuer-Vertrauen; mit authentifiziertem Kontext abgleichen.

Gängige Organisationskennung in SaaS-Autorisierungsmodellen.

Validierung: Als issuer-spezifischen Wert behandeln und Resource Membership separat erzwingen.

Anbieter-Konvention zur Unterscheidung von Access- und Identity-Token.

Validierung: Nur nach offizieller Issuer-Dokumentation verwenden; Standard-typ/profile bevorzugen.