OBS/Kostenpflichtige Module/RESTServer/Zugaenge - Versionsgeschichte

MINERVA-Rademacker: Fehlercode AUTH_FAILED und Obergrenze der Refresh-Laufzeit ergaenzt [Volltext ersetzt]

2026-09-25T09:28:33Z

Fehlercode AUTH_FAILED und Obergrenze der Refresh-Laufzeit ergaenzt [Volltext ersetzt]

← Nächstältere Version		Version vom 25. September 2026, 10:28 Uhr
Zeile 166:		Zeile 166:
	* ''_OBS_JWT_CLAIM_<name>'' für beliebige Custom-Claims (z.B. Mandant ''tenant'', Rollen ''roles''); im Folge-Skript lesbar		* ''_OBS_JWT_CLAIM_<name>'' für beliebige Custom-Claims (z.B. Mandant ''tenant'', Rollen ''roles''); im Folge-Skript lesbar
	* ''_OBS_JWT_REFRESH_ID'' (optional) löst die Ausstellung eines Refresh-Tokens aus; ''_OBS_JWT_REFRESH_EXP'' setzt dessen Lebensdauer in Minuten (Default 90 Tage)		* ''_OBS_JWT_REFRESH_ID'' (optional) löst die Ausstellung eines Refresh-Tokens aus; ''_OBS_JWT_REFRESH_EXP'' setzt dessen Lebensdauer in Minuten (Default 90 Tage)

			{{Achtung\|Die Lebensdauer eines Refresh-Tokens ist nach oben auf '''372 Tage'''
			begrenzt. Ein mit ''_OBS_JWT_REFRESH_EXP'' länger ausgestelltes Token wird bei der
			Vorlage '''nicht mehr verifiziert''' und mit 401 abgewiesen - der Fehler fällt
			also erst Monate später auf, beim ersten Erneuerungsversuch.}}

	Die Signatur lautet ''procedure Authenticate(oReader: TxRestReader; oWriter: TxRestWriter);'' - Details unter [[OBS/Kostenpflichtige Module/RESTServer/Scripting\|Scripting]]. Bei Erfolg signiert der Server einen Token (HS256, Issuer ''OBS REST-Server'', Lebenszeit gemäß JWT-Exp) und antwortet:		Die Signatur lautet ''procedure Authenticate(oReader: TxRestReader; oWriter: TxRestWriter);'' - Details unter [[OBS/Kostenpflichtige Module/RESTServer/Scripting\|Scripting]]. Bei Erfolg signiert der Server einen Token (HS256, Issuer ''OBS REST-Server'', Lebenszeit gemäß JWT-Exp) und antwortet:
Zeile 194:		Zeile 199:

	Wird die Anmeldung abgelehnt (''status'' = 9), antwortet der Server mit		Wird die Anmeldung abgelehnt (''status'' = 9), antwortet der Server mit
	'''401 Unauthorized''' und reicht den Text aus dem Feld ''error'' als		'''401 Unauthorized''', dem Code ''AUTH_FAILED'' und reicht den Text aus dem Feld
	''error.message'' an den Client durch - der Konsument kann ihn also direkt		''error'' als ''error.message'' an den Client durch - der Konsument kann ihn also
	anzeigen. Die Formulierung liegt damit beim Skript.		direkt anzeigen. Die Formulierung liegt damit beim Skript.

			{{Hinweis\|''AUTH_FAILED'' unterscheidet die '''abgelehnte Anmeldung''' vom
			''AUTH_EXPIRED'', das ein abgelaufenes oder gesperrtes Token liefert. Ein Client
			sollte auf den Code reagieren und nicht auf den Text: Bei ''AUTH_FAILED'' gehört
			die Anmeldemaske noch einmal vorgelegt, bei ''AUTH_EXPIRED'' erst ein Refresh
			versucht.}}

	{{Hinweis\|Der durchgereichte Text ist für den Endanwender gedacht und sollte		{{Hinweis\|Der durchgereichte Text ist für den Endanwender gedacht und sollte

Rademacker am 14. September 2026 um 08:07 Uhr

2026-09-14T08:07:19Z

← Nächstältere Version		Version vom 14. September 2026, 09:07 Uhr
Zeile 44:		Zeile 44:

	{{Hinweis\|Ein Zugang mit API-Key ''*'' sollte nur für bewusst freigegebene Endpunkte verwendet werden und immer in Kombination mit einer Host-Beschränkung oder CORS-Beschränkung betrieben werden.}}		{{Hinweis\|Ein Zugang mit API-Key ''*'' sollte nur für bewusst freigegebene Endpunkte verwendet werden und immer in Kombination mit einer Host-Beschränkung oder CORS-Beschränkung betrieben werden.}}

			{{Achtung\|'''Nur für wirklich öffentliche Dateien.''' Ohne API-Key kennt der
			Endpunkt weder Mandant noch Rolle - es gibt nichts, woran er eine Berechtigung
			festmachen könnte ausser dem, was in der URL steht. Ein Wildcard-Zugang eignet
			sich deshalb für Artefakte, die für jeden bestimmt sind (Test-APK, Handbuch),
			'''nicht''' für Kundenbelege. Siehe
			[[OBS/Kostenpflichtige Module/RESTServer/Datei-Download\|Datei-Download]].}}

			{{Hinweis\|Bei einem Wildcard-Zugang sollte ''CORS-Origin'' '''leer''' bleiben.
			Ein ''*'' dort wirkt auf die Preflight-Antwort '''aller''' Zugänge (siehe unten);
			ein Download über die Adresszeile des Browsers sendet ohnehin kein ''Origin'',
			CORS greift dort also gar nicht.}}

	==Host-Beschränkung==		==Host-Beschränkung==

Rademacker am 9. September 2026 um 12:30 Uhr

2026-09-09T12:30:38Z

← Nächstältere Version		Version vom 9. September 2026, 13:30 Uhr
Zeile 147:		Zeile 147:
	Body: {"username":"...", "password":"..."}		Body: {"username":"...", "password":"..."}

	Der Server führt das im Zugang hinterlegte '''Authentifizierungs-Skript''' aus (F7 in der Zugangs-Liste). Das Skript muss eine ~~Funktion~~ ''Authenticate'' bereitstellen, die ~~ein JSON-Objekt mit~~:		Der Server führt das im Zugang hinterlegte '''Authentifizierungs-Skript''' aus (F7 in der Zugangs-Liste). Das Skript muss eine Prozedur ''Authenticate'' bereitstellen, die über den Writer schreibt:

	* ''status'' = ''1'' bei Erfolg, ''9'' bei Misserfolg		* ''status'' = ''1'' bei Erfolg, ''9'' bei Misserfolg
Zeile 155:		Zeile 155:
	* ''_OBS_JWT_REFRESH_ID'' (optional) löst die Ausstellung eines Refresh-Tokens aus; ''_OBS_JWT_REFRESH_EXP'' setzt dessen Lebensdauer in Minuten (Default 90 Tage)		* ''_OBS_JWT_REFRESH_ID'' (optional) löst die Ausstellung eines Refresh-Tokens aus; ''_OBS_JWT_REFRESH_EXP'' setzt dessen Lebensdauer in Minuten (Default 90 Tage)

	~~zurückliefert~~. Bei Erfolg signiert der Server einen Token (HS256, Issuer ''OBS REST-Server'', Lebenszeit gemäß JWT-Exp) und antwortet:		Die Signatur lautet ''procedure Authenticate(oReader: TxRestReader; oWriter: TxRestWriter);'' - Details unter [[OBS/Kostenpflichtige Module/RESTServer/Scripting\|Scripting]]. Bei Erfolg signiert der Server einen Token (HS256, Issuer ''OBS REST-Server'', Lebenszeit gemäß JWT-Exp) und antwortet:

	{"token": "eyJhbGciOi...",		{"token": "eyJhbGciOi...",
Zeile 261:		Zeile 261:
	Der Fall „Gerät verloren" ist bewusst '''nicht''' am JWT-Endpunkt untergebracht:		Der Fall „Gerät verloren" ist bewusst '''nicht''' am JWT-Endpunkt untergebracht:
	er braucht eine fachliche Entscheidung darüber, wer das darf. Dafür gibt es das		er braucht eine fachliche Entscheidung darüber, wer das darf. Dafür gibt es das
	~~Antwortfeld~~ ''~~_OBS_JWT_REVOKE~~'', das jeder gewöhnliche Endpunkt ~~setzen~~ kann:		''oWriter.JwtRevoke'', das jeder gewöhnliche Endpunkt aufrufen kann:

	<syntaxhighlight lang="pascal" line>		<syntaxhighlight lang="pascal" line>
	~~function~~ Post(~~oParams~~: ~~TStrings~~; ~~oBody~~: ~~TJSONObject~~)~~: string;~~		procedure Post(oReader: TxRestReader; oWriter: TxRestWriter);
	~~var oRes: TJSONObject~~;
	begin		begin
	~~oRes := TJSONObject.Create();~~		// 'session' = nur diese Sitzung, 'all' = alle Sitzungen des Subjects
	~~try~~		oWriter.JwtRevoke('all');
	// 'session' = nur diese Sitzung, 'all' = alle Sitzungen des Subjects		oWriter.Status(204);
	~~oRes~~.~~AddPair~~(~~'_OBS_JWT_REVOKE' ,~~ 'all');		oWriter.NoBody();
	~~oRes~~.~~AddPair~~(~~'_OBS_HTTP_STATUS',~~ 204);
	~~result := oRes~~.~~ToJSON~~();
	~~finally~~
	~~MyFreeAndNil(oRes);~~
	~~end~~;
	end;		end;
	</syntaxhighlight>		</syntaxhighlight>
Zeile 282:		Zeile 276:
	gesetzt hat. Ohne Subject lässt sich die Menge der Sitzungen nicht bestimmen, und		gesetzt hat. Ohne Subject lässt sich die Menge der Sitzungen nicht bestimmen, und
	der Aufruf antwortet mit 503.}}		der Aufruf antwortet mit 503.}}

			==Woher ein Anmelder seine Identität bekommt==

			'''Diese Frage entscheidet das Skript des Zugangs, nicht der Server.''' Das
			Authentifizierungs-Skript liegt je Zugang in <code>ra_jwt_script</code> - und
			damit gilt für jede Anwendung ihre eigene Regel.

			Das ist keine Kleinigkeit, sondern der Punkt, an dem sich zwei Anwendungen
			unterscheiden. Ein Beispiel aus dem Betrieb: Ein Zugang für eine
			Techniker-Anwendung lehnt jeden Benutzer ohne Mitarbeiterzuordnung
			(<code>BENUTZ.b_mitarbeiter</code>) ab - '''bewusst''', denn ein Techniker ohne
			Zuordnung bekäme eine leere Auftragsliste und würde den Fehler bei sich suchen.
			Für einen Kundenzugang wäre genau dieselbe Regel falsch: sie träfe '''jeden'''
			Anmelder.

			Wer einen zweiten Zugang für eine andere Anwendung anlegt, prüft deshalb als
			Erstes: Woraus besteht die Identität dieser Anmelder, und welche Ablehnung ist
			für sie richtig? Ein kopiertes Skript bringt die Regel der anderen Anwendung
			mit, und sie fällt erst auf, wenn sich der erste echte Anmelder nicht anmelden
			kann.

	==Sitzungen (RESTSRV_TOKEN)==		==Sitzungen (RESTSRV_TOKEN)==

Rademacker am 20. August 2026 um 07:30 Uhr

2026-08-20T07:30:52Z

@@ Zeile 22: / Zeile 22: @@
 | Host          || Optionaler Hostname oder IP-Adresse des Konsumenten. Stimmt die anfragende IP nicht überein, wird mit 403 abgelehnt
 |-
-| CORS-Origins  || Liste erlaubter Origins für Browser-Aufrufe, mehrere durch '';'' getrennt
+| CORS-Origins  || Liste erlaubter Origins für Browser-Aufrufe, mehrere durch '';'' getrennt. '''Leer heisst nicht „keine Einschränkung", sondern „kein Browser-Zugriff"''' - siehe unten
 |-
 | mTLS-Subject  || Erwartete RDN-Komponente(n) im Client-Zertifikat-Subject, Komma-/Semikolon-getrennt (alle müssen vorkommen; nur sinnvoll bei mTLS-Servern)
@@ Zeile 59: / Zeile 59: @@
 Ablauf:
-# Browser sendet einen Preflight-Request (''OPTIONS''). Der REST-Server prüft das Origin gegen die globale Origin-Liste aller Accounts (Cache, TTL 60s) und antwortet mit 204 + CORS-Header, falls erlaubt.
+# Browser sendet einen Preflight-Request (''OPTIONS''). Der REST-Server prüft das Origin gegen die globale Origin-Liste '''aller''' Accounts (Cache, TTL 60s) und antwortet mit 204 + CORS-Header, falls erlaubt.
-# Der eigentliche Request wird gegen die Origin-Liste des aktuell verwendeten Zugangs geprüft.
+# Der eigentliche Request wird gegen die Origin-Liste '''des aktuell verwendeten Zugangs''' geprüft.
 # Stimmt das Origin nicht, wird mit 403 ''Origin nicht erlaubt für Account ...'' abgelehnt.
-Erlaubte Methoden: ''GET, POST, PUT, DELETE, PATCH''. Erlaubte Header: ''Content-Type, apikey, Authorization, Accept''. Diese Werte sind systemseitig festgelegt und werden in der Preflight-Antwort zurückgegeben.
+Der Preflight kann nicht zugangsbezogen prüfen: der Browser schickt dabei keinen
 ==JWT-Authentifizierung==

Rademacker am 19. August 2026 um 12:00 Uhr

2026-08-19T12:00:08Z

@@ Zeile 28: / Zeile 28: @@
 | JWT           || Schalter, ob für diesen Zugang ein JWT-Token nötig ist
 |-
-| JWT-Endpunkt  || Pfad, über den der JWT-Token bezogen wird (z.B. ''oauth'' oder ''meineapp/dev/auth/login''). Verglichen wird der '''vollständige Pfad''', mehrstufige Angaben mit ''/'' sind also erlaubt
+| JWT-Endpunkt  || Pfad, über den '''alle Token-Vorgänge''' laufen: Anmelden, Erneuern und Abmelden (z.B. ''oauth'' oder ''meineapp/dev/auth''). Verglichen wird der '''vollständige Pfad''', mehrstufige Angaben mit ''/'' sind also erlaubt
 |-
 | JWT-Key       || Geheimer Schlüssel zur Signierung/Verifikation, per Schlüsselsymbol generierbar
@@ Zeile 67: / Zeile 67: @@
 ==JWT-Authentifizierung==
-Wird ein Zugang mit aktiver JWT-Pflicht aufgerufen, sind die folgenden Phasen zu durchlaufen (Phase 3 nur bei genutztem Refresh):
+Wird ein Zugang mit aktiver JWT-Pflicht aufgerufen, sind die folgenden Phasen zu durchlaufen (Phase 3 nur bei genutztem Refresh).
 ===Phase 1: Token-Bezug===
@@ Zeile 167: / Zeile 192: @@
 ===Phase 4: Abmelden (Logout)===
-Ein Abmelden ist ein gewöhnlicher Endpunkt, der die Sitzung des vorgelegten
+Abgemeldet wird mit einem '''DELETE''' auf denselben JWT-Endpunkt, das
-Tokens sperrt. Dafür genügt ein Antwortfeld, das Skript braucht keine eigene
+Access-Token im ''Authorization''-Header:
-Verwaltung:
 <syntaxhighlight lang="pascal" line>
@@ Zeile 177: / Zeile 224: @@
      oRes := TJSONObject.Create();
      try
-         oRes.AddPair('_OBS_JWT_REVOKE' , 'session');   // 'all' = alle Sitzungen des Benutzers
+        // 'session' = nur diese Sitzung, 'all' = alle Sitzungen des Subjects
          oRes.AddPair('_OBS_HTTP_STATUS', 204);
          result := oRes.ToJSON();
@@ Zeile 185: / Zeile 233: @@
 end;
 </syntaxhighlight>
 {{Hinweis|''all'' setzt voraus, dass das Authenticate-Skript ''_OBS_JWT_SUBJECT''

Rademacker am 19. August 2026 um 10:13 Uhr

2026-08-19T10:13:51Z

@@ Zeile 103: / Zeile 103: @@
    "token": "eyJ...", "accessToken": "eyJ...", "refreshToken": "eyJ...",
    "expiresIn": 28800, "serverTime": "2026-06-29T15:30:12+02:00"}
 Wird die Anmeldung abgelehnt (''status'' = 9), antwortet der Server mit
@@ Zeile 121: / Zeile 128: @@
           Authorization: Bearer eyJhbGciOi...
-Der Server verifiziert Signatur, Issuer, Ausstellzeitpunkt und Ablauf (Toleranz: 20 Sekunden Clock-Skew). Im Skript stehen die Claims als Parameter ''_OBS_JWT_ID'', ''_OBS_JWT_SUBJECT'' und ''_OBS_JWT_AUDIENCE'' zur Verfügung.
+Der Server verifiziert Signatur, Issuer, Ausstellzeitpunkt und Ablauf (Toleranz: 20 Sekunden Clock-Skew) und prüft anschliessend die '''Sitzung''' in ''RESTSRV_TOKEN''. Im Skript stehen die Claims als Parameter ''_OBS_JWT_ID'', ''_OBS_JWT_SUBJECT'' und ''_OBS_JWT_AUDIENCE'' zur Verfügung.
 ===Phase 3: Token erneuern (Refresh)===
@@ Zeile 131: / Zeile 146: @@
           Authorization: Bearer eyJhbGciOi... (Refresh-Token)
-Der Server erkennt am Bearer-Token den Refresh-Fall, verifiziert das Token (Signatur, Ablauf, ''token_use=refresh'') und ruft im selben Skript die Methode '''Refresh''' auf. Das Skript prüft seine Sperrtabelle, rotiert das Refresh-jti und liefert neue Claims. Der Server antwortet mit einem rotierten Paar ''{"token","refreshToken","serverTime"}''. Ein bereits benutztes (rotiertes) Refresh-Token wird mit 401 abgelehnt.
+Der Server erkennt am Bearer-Token den Refresh-Fall, verifiziert das Token (Signatur, Ablauf, ''token_use=refresh''), '''entwertet es in der Sitzung''' und ruft erst dann im selben Skript die Methode '''Refresh''' auf. Das Skript liefert nur noch die aktuellen Claims zurück - Rotation, Einmalgebrauch und Sperrliste erledigt der Server. Die Antwort ist ein rotiertes Paar ''{"token","accessToken","refreshToken","expiresIn","serverTime"}'' in '''derselben Sitzung'''.
 Details und ein vollständiges Beispiel siehe [[OBS/Kostenpflichtige Module/RESTServer/Scripting|Scripting]].
 ==mTLS-Subject-Prüfung==

Rademacker am 17. August 2026 um 06:49 Uhr

2026-08-17T06:49:52Z

← Nächstältere Version		Version vom 17. August 2026, 07:49 Uhr
Zeile 28:		Zeile 28:
	\| JWT \|\| Schalter, ob für diesen Zugang ein JWT-Token nötig ist		\| JWT \|\| Schalter, ob für diesen Zugang ein JWT-Token nötig ist
	\|-		\|-
	\| JWT-Endpunkt \|\| ~~Adresse~~, über ~~die~~ der JWT-Token bezogen wird (z.B. ''oauth''), ~~darf keinen~~ ''/'' ~~enthalten~~		\| JWT-Endpunkt \|\| Pfad, über den der JWT-Token bezogen wird (z.B. ''oauth'' oder ''meineapp/dev/auth/login''). Verglichen wird der '''vollständige Pfad''', mehrstufige Angaben mit ''/'' sind also erlaubt
	\|-		\|-
	\| JWT-Key \|\| Geheimer Schlüssel zur Signierung/Verifikation, per Schlüsselsymbol generierbar		\| JWT-Key \|\| Geheimer Schlüssel zur Signierung/Verifikation, per Schlüsselsymbol generierbar
	\|-		\|-
	\| JWT-Exp \|\| Gültigkeitsdauer eines ausgestellten Tokens in Minuten		\| JWT-Exp \|\| Gültigkeitsdauer eines ausgestellten Access-Tokens in '''Minuten'''. Derselbe Wert wird dem Konsumenten in der Token-Antwort als ''expiresIn'' in '''Sekunden''' mitgeteilt und steht dem Endpunkt-Skript als ''_OBS_JWT_EXP_SEC'' zur Verfügung
	\|}		\|}

Zeile 82:		Zeile 82:
	* ''error'' = Fehlertext (bei status=9)		* ''error'' = Fehlertext (bei status=9)
	* ''_OBS_JWT_ID'', ''_OBS_JWT_SUBJECT'', ''_OBS_JWT_AUDIENCE'' für die JWT-Claims (optional)		* ''_OBS_JWT_ID'', ''_OBS_JWT_SUBJECT'', ''_OBS_JWT_AUDIENCE'' für die JWT-Claims (optional)
	* ''_OBS_JWT_CLAIM_<name>'' ~~fÜr~~ beliebige Custom-Claims (z.B. Mandant ''tenant'', Rollen ''roles''); im Folge-Skript lesbar		* ''_OBS_JWT_CLAIM_<name>'' für beliebige Custom-Claims (z.B. Mandant ''tenant'', Rollen ''roles''); im Folge-Skript lesbar
	* ''_OBS_JWT_REFRESH_ID'' (optional) ~~lÖst~~ die Ausstellung eines Refresh-Tokens aus; ''_OBS_JWT_REFRESH_EXP'' setzt dessen Lebensdauer in Minuten (Default 90 Tage)		* ''_OBS_JWT_REFRESH_ID'' (optional) löst die Ausstellung eines Refresh-Tokens aus; ''_OBS_JWT_REFRESH_EXP'' setzt dessen Lebensdauer in Minuten (Default 90 Tage)

	zurückliefert. Bei Erfolg signiert der Server einen Token (HS256, Issuer ''OBS REST-Server'', Lebenszeit gemäß JWT-Exp) und antwortet:		zurückliefert. Bei Erfolg signiert der Server einen Token (HS256, Issuer ''OBS REST-Server'', Lebenszeit gemäß JWT-Exp) und antwortet:

	{"token": "eyJhbGciOi...", "serverTime": "2026-06-29T15:30:12+02:00"}		{"token": "eyJhbGciOi...",
			"accessToken": "eyJhbGciOi...",
			"expiresIn": 28800,
			"serverTime": "2026-06-29T15:30:12+02:00"}

			Zum Aufbau der Antwort:

			* ''token'' und ''accessToken'' enthalten '''denselben''' Token. ''accessToken'' ist der Name, den die meisten Client-Bibliotheken erwarten; ''token'' bleibt für bestehende Konsumenten erhalten.
			* ''expiresIn'' ist die Gültigkeit in '''Sekunden''' (JWT-Exp × 60).
			* '''Alle weiteren Felder, die das Authenticate-Skript zurückgibt, werden mit ausgeliefert''' - mit Ausnahme von ''status'' und den ''_OBS_''-Steuerfeldern. So kann das Skript z.B. eine Benutzer-Id, den Mandanten oder Rollen direkt in die Anmelde-Antwort legen, ohne dass der Client dafür einen zweiten Aufruf braucht.

			Beispiel mit Zusatzfeldern aus dem Skript:

			{"benutzerId": "4711", "tenant": "nord", "roles": ["TECHNIKER"],
			"token": "eyJ...", "accessToken": "eyJ...", "refreshToken": "eyJ...",
			"expiresIn": 28800, "serverTime": "2026-06-29T15:30:12+02:00"}

			Wird die Anmeldung abgelehnt (''status'' = 9), antwortet der Server mit
			'''401 Unauthorized''' und reicht den Text aus dem Feld ''error'' als
			''error.message'' an den Client durch - der Konsument kann ihn also direkt
			anzeigen. Die Formulierung liegt damit beim Skript.

			{{Hinweis\|Der durchgereichte Text ist für den Endanwender gedacht und sollte
			keine internen Details verraten. „Benutzer oder Passwort ist falsch" ist eine gute
			Meldung, „Kein Datensatz in BENUTZ mit b_name=meier" nicht.}}

	===Phase 2: Token-Verwendung===		===Phase 2: Token-Verwendung===
Zeile 101:		Zeile 125:
	===Phase 3: Token erneuern (Refresh)===		===Phase 3: Token erneuern (Refresh)===

	Soll die App lange ohne Neuanmeldung arbeiten, stellt das Authenticate-Skript ~~zusÄtzlich~~ ein Refresh-Token aus (Feld ''_OBS_JWT_REFRESH_ID''). Zum Erneuern ruft der Client '''denselben JWT-Endpunkt''' auf, aber mit dem Refresh-Token im ''Authorization''-Header:		Soll die App lange ohne Neuanmeldung arbeiten, stellt das Authenticate-Skript zusätzlich ein Refresh-Token aus (Feld ''_OBS_JWT_REFRESH_ID''). Zum Erneuern ruft der Client '''denselben JWT-Endpunkt''' auf, aber mit dem Refresh-Token im ''Authorization''-Header:

	POST https://api.meinserver.de/oauth/		POST https://api.meinserver.de/oauth/
Zeile 107:		Zeile 131:
	Authorization: Bearer eyJhbGciOi... (Refresh-Token)		Authorization: Bearer eyJhbGciOi... (Refresh-Token)

	Der Server erkennt am Bearer-Token den Refresh-Fall, verifiziert das Token (Signatur, Ablauf, ''token_use=refresh'') und ruft im selben Skript die Methode '''Refresh''' auf. Das Skript ~~prÜft~~ seine Sperrtabelle, rotiert das Refresh-jti und liefert neue Claims. Der Server antwortet mit einem rotierten Paar ''{"token","refreshToken","serverTime"}''. Ein bereits benutztes (rotiertes) Refresh-Token wird mit 401 abgelehnt.		Der Server erkennt am Bearer-Token den Refresh-Fall, verifiziert das Token (Signatur, Ablauf, ''token_use=refresh'') und ruft im selben Skript die Methode '''Refresh''' auf. Das Skript prüft seine Sperrtabelle, rotiert das Refresh-jti und liefert neue Claims. Der Server antwortet mit einem rotierten Paar ''{"token","refreshToken","serverTime"}''. Ein bereits benutztes (rotiertes) Refresh-Token wird mit 401 abgelehnt.
	Details und ein vollständiges Beispiel siehe [[OBS/Kostenpflichtige Module/RESTServer/Scripting\|Scripting]].		Details und ein vollständiges Beispiel siehe [[OBS/Kostenpflichtige Module/RESTServer/Scripting\|Scripting]].

Rademacker am 29. Juni 2026 um 10:09 Uhr

2026-06-29T10:09:01Z

← Nächstältere Version		Version vom 29. Juni 2026, 11:09 Uhr
Zeile 67:		Zeile 67:
	==JWT-Authentifizierung==		==JWT-Authentifizierung==

	Wird ein Zugang mit aktiver JWT-Pflicht aufgerufen, sind ~~zwei~~ Phasen zu durchlaufen:		Wird ein Zugang mit aktiver JWT-Pflicht aufgerufen, sind die folgenden Phasen zu durchlaufen (Phase 3 nur bei genutztem Refresh):

	===Phase 1: Token-Bezug===		===Phase 1: Token-Bezug===
Zeile 82:		Zeile 82:
	* ''error'' = Fehlertext (bei status=9)		* ''error'' = Fehlertext (bei status=9)
	* ''_OBS_JWT_ID'', ''_OBS_JWT_SUBJECT'', ''_OBS_JWT_AUDIENCE'' für die JWT-Claims (optional)		* ''_OBS_JWT_ID'', ''_OBS_JWT_SUBJECT'', ''_OBS_JWT_AUDIENCE'' für die JWT-Claims (optional)
			* ''_OBS_JWT_CLAIM_<name>'' fÜr beliebige Custom-Claims (z.B. Mandant ''tenant'', Rollen ''roles''); im Folge-Skript lesbar
			* ''_OBS_JWT_REFRESH_ID'' (optional) lÖst die Ausstellung eines Refresh-Tokens aus; ''_OBS_JWT_REFRESH_EXP'' setzt dessen Lebensdauer in Minuten (Default 90 Tage)

	zurückliefert. Bei Erfolg signiert der Server einen Token (HS256, Issuer ''OBS REST-Server'', Lebenszeit gemäß JWT-Exp) und antwortet:		zurückliefert. Bei Erfolg signiert der Server einen Token (HS256, Issuer ''OBS REST-Server'', Lebenszeit gemäß JWT-Exp) und antwortet:

	{"token": "eyJhbGciOi..."}		{"token": "eyJhbGciOi...", "serverTime": "2026-06-29T15:30:12+02:00"}

	===Phase 2: Token-Verwendung===		===Phase 2: Token-Verwendung===
Zeile 97:		Zeile 99:
	Der Server verifiziert Signatur, Issuer, Ausstellzeitpunkt und Ablauf (Toleranz: 20 Sekunden Clock-Skew). Im Skript stehen die Claims als Parameter ''_OBS_JWT_ID'', ''_OBS_JWT_SUBJECT'' und ''_OBS_JWT_AUDIENCE'' zur Verfügung.		Der Server verifiziert Signatur, Issuer, Ausstellzeitpunkt und Ablauf (Toleranz: 20 Sekunden Clock-Skew). Im Skript stehen die Claims als Parameter ''_OBS_JWT_ID'', ''_OBS_JWT_SUBJECT'' und ''_OBS_JWT_AUDIENCE'' zur Verfügung.

			===Phase 3: Token erneuern (Refresh)===

			Soll die App lange ohne Neuanmeldung arbeiten, stellt das Authenticate-Skript zusÄtzlich ein Refresh-Token aus (Feld ''_OBS_JWT_REFRESH_ID''). Zum Erneuern ruft der Client '''denselben JWT-Endpunkt''' auf, aber mit dem Refresh-Token im ''Authorization''-Header:

			POST https://api.meinserver.de/oauth/
			Header: apikey: [API-KEY]
			Authorization: Bearer eyJhbGciOi... (Refresh-Token)

			Der Server erkennt am Bearer-Token den Refresh-Fall, verifiziert das Token (Signatur, Ablauf, ''token_use=refresh'') und ruft im selben Skript die Methode '''Refresh''' auf. Das Skript prÜft seine Sperrtabelle, rotiert das Refresh-jti und liefert neue Claims. Der Server antwortet mit einem rotierten Paar ''{"token","refreshToken","serverTime"}''. Ein bereits benutztes (rotiertes) Refresh-Token wird mit 401 abgelehnt.
	Details und ein vollständiges Beispiel siehe [[OBS/Kostenpflichtige Module/RESTServer/Scripting\|Scripting]].		Details und ein vollständiges Beispiel siehe [[OBS/Kostenpflichtige Module/RESTServer/Scripting\|Scripting]].

Rademacker am 15. Juni 2026 um 07:24 Uhr

2026-06-15T07:24:36Z

← Nächstältere Version		Version vom 15. Juni 2026, 08:24 Uhr
Zeile 24:		Zeile 24:
	\| CORS-Origins \|\| Liste erlaubter Origins für Browser-Aufrufe, mehrere durch '';'' getrennt		\| CORS-Origins \|\| Liste erlaubter Origins für Browser-Aufrufe, mehrere durch '';'' getrennt
	\|-		\|-
	\| mTLS-Subject \|\| ~~Erwarteter Substring~~ im Client-Zertifikat-Subject (nur sinnvoll bei mTLS-Servern)		\| mTLS-Subject \|\| Erwartete RDN-Komponente(n) im Client-Zertifikat-Subject, Komma-/Semikolon-getrennt (alle müssen vorkommen; nur sinnvoll bei mTLS-Servern)
	\|-		\|-
	\| JWT \|\| Schalter, ob für diesen Zugang ein JWT-Token nötig ist		\| JWT \|\| Schalter, ob für diesen Zugang ein JWT-Token nötig ist
Zeile 101:		Zeile 101:
	==mTLS-Subject-Prüfung==		==mTLS-Subject-Prüfung==

	Wird im Feld '''mTLS-Subject''' ein Wert hinterlegt, prüft der Server zusätzlich zur Standard-mTLS-Validierung, ob der Subject-DN des Client-Zertifikats ~~den~~ hinterlegten ~~Text~~ enthält (~~case-insensitiv,~~ Substring-Match).		Wird im Feld '''mTLS-Subject''' ein Wert hinterlegt, prüft der Server zusätzlich zur Standard-mTLS-Validierung, ob der Subject-DN des (CA-validierten) Client-Zertifikats die hinterlegten '''RDN-Komponenten''' enthält. Verglichen wird jede Komponente '''vollständig''' (kein Substring-Match) und case-insensitiv; mehrere Komponenten werden durch Komma oder Semikolon getrennt und müssen '''alle''' im Subject vorkommen.

	Beispiele für Subject-Strings im Cert:		Beispiele für Subject-Strings im Cert (OneLine-DN):

	/C=DE/O=Kunde GmbH/CN=client-prod.kunde.de		/C=DE/O=Kunde GmbH/CN=client-prod.kunde.de
	/C=DE/O=Kunde GmbH/CN=client-test.kunde.de		/C=DE/O=Kunde GmbH/CN=client-test.kunde.de

	Mit '''CN=client-prod''' im Feld wird genau das prod-Cert akzeptiert, das test-Cert ~~wird~~ mit 401 abgewiesen. ~~Damit~~ lassen sich ~~verschiedene Konsumenten über dieselbe CA klar voneinander trennen~~.		Mit '''CN=client-prod.kunde.de''' im Feld wird genau das prod-Cert akzeptiert, das test-Cert mit 401 abgewiesen. Da jede RDN-Komponente vollständig verglichen wird, matcht z.B. '''CN=client1''' nicht fälschlich auch '''CN=client10'''. Mehrere Bedingungen lassen sich mit Komma/Semikolon kombinieren, z.B. ''O=Kunde GmbH;CN=client-prod.kunde.de''.

	==Listen-Funktionen==		==Listen-Funktionen==

Rademacker am 19. Mai 2026 um 06:11 Uhr

2026-05-19T06:11:02Z

Änderungen zeigen