POST/api/auth/sso/exchange

Posledný krok pri prihlásení prostredníctvom SSO (SAML/OIDC): vymení jednorazový kód vydaný callbackom za bežné session-JWT.

Stránka „POST /api/auth/sso/exchange — referencia API“ sa venuje funkčnej oblasti označenej v URL. Existujúci obsah sa dopĺňa o skutočný priebeh, predpoklady a známe obmedzenia. Zentor nemá systém API kľúčov pre vývojárov. Pre dashboard sa používajú session JWT s platnosťou dvanásť hodín a refresh tokeny s platnosťou sedem dní; TOTP a SSO sú voliteľné. Embed tokeny widgetu sa zobrazia jednorazovo v otvorenom texte a sú viazané na povolené pôvody (origins). Dokumentáciu k `POST /api/auth/sso/exchange` treba záväzne čítať ako technický popis tohto konkrétneho koncového bodu. Rozhodujúce sú metóda, cesta, autentifikácia, povinné polia, možné chyby a otázka, či opakované volanie vyvolá rovnaký účinok. Táto sekcia pomocníka https://zentor-app.de/hilfe/api-referenz/auth/auth.sso_exchange preto nesmie obsahovať všeobecné reklamné tvrdenia, ale iba zrozumiteľné integračné kroky a doložené príklady odpovedí. Pri volaní `/api/auth/sso/exchange` sa požiadavka zostavuje podľa registra (Registry). Verejné cesty nepotrebujú všeobecný API kľúč pre vývojárov, pretože Zentor takýto systém kľúčov neponúka. Chránené cesty widgetu naopak používajú jednorazovo zobrazený embed token a kontrolu pôvodu (Origin). Stav HTTP a obsah JSON sa musia vyhodnocovať spoločne; samotné pole `ok` nenahrádza ošetrenie chýb. Pri testovaní `POST /api/auth/sso/exchange` treba používať anonymizované hodnoty. Skutočné údaje zákazníkov, produktívne UUID, tokeny relácií a konkrétne časové pečiatky nepatria do verejných príkladov. Známy limit pre celú platformu je 2.000 požiadaviek v priebehu 15 minút; odlišný samostatný limit nie je doložený. Neidempotentné volania POST sa po nejasnom prerušení siete nesmú naslepo opakovať. Typické integračné chyby pri tejto ceste vznikajú v dôsledku chýbajúcich povinných parametrov, nesprávnych dátových typov, vypršaných jednorazových kódov, nepovolených pôvodov (origins) alebo neimplementovaného záznamu. Aplikácia by mala takéto prípady ošetrovať oddelene a chybové hlásenie vrátené koncovým bodom zaprotokolovať bez zaznamenávania tajných údajov. Úspešná požiadavka potvrdzuje iba tento krok spracovania, nie automaticky následný úspech e-mailu, platby alebo SSO. Pre „POST /api/auth/sso/exchange“ je to priamo relevantné. Technická kontrola tejto stránky sa musí záväzne opierať o register v `app/frontend/src/content/api-reference/` a príslušné backendové cesty. Poznámky k živým testom smú tvrdiť iba to, čo bolo skutočne overené. Negatívny test ani analógia v kóde nie sú úplným dôkazom úspechu. Pri stránke POST /api/auth/sso/exchange — referencia API preto treba jasne rozlišovať medzi zdokumentovanou štruktúrou, automatizovaným testom a spoľahlivo pozorovaným správaním v živej prevádzke.

{"code":"<jednorazový kód z presmerovania SSO callbacku>"}

{"ok":true,"token":"<JWT>","refreshToken":"<Refresh-Token>"}