POST/api/auth/sso/exchange

Az SSO-bejelentkezés utolsó lépése (SAML/OIDC): a callback által kiadott egyszeri kódot cseréli le egy szabályos session JWT-re.

A „POST /api/auth/sso/exchange — API-Referenz“ oldal a URL-ben jelölt funkcióterületet tárgyalja. A meglévő tartalmat kiegészítjük a tényleges folyamat, az előfeltételek és a ismert korlátok leírásával. A Zentor nem rendelkezik fejlesztői API-kulcs-rendszerrel. A műszerfalhoz 12 órás érvényességi idejű session JWT-ket és 7 napos érvényességi idejű refresh tokeneket használunk; a TOTP és az SSO opcionális. A widget-embed tokenek egyszeri alkalommal jelennek meg tisztaszöveges formátumban, és engedélyezett origókhoz vannak kötve. A `POST /api/auth/sso/exchange` dokumentációját egyértelműen a konkrét végpont technikai leírásaként kell értelmezni. Döntő fontosságú a módszer, az elérési út, a hitelesítés, a kötelező mezők, a lehetséges hibák és az a kérdés, hogy egy újrahívás ugyanazt a hatást váltja-e ki. Ez a súgószakasz (https://zentor-app.de/hilfe/api-referenz/auth/auth.sso_exchange) ezért nem tartalmazhat általános reklámállítást, csupán utólag ellenőrizhető integrációs lépéseket és igazolt válasz példákat. A `/api/auth/sso/exchange` hívásához a kérést a Registry szerint kell felépíteni. A nyilvános útvonalakhoz nem szükséges általános fejlesztői API-kulcs, mivel a Zentor nem kínál ilyen kulcsrendszert. A védett widget-útvonalak ezzel szemben az egyszeri megjelenítésű embed tokent és egy origin-ellenőrzést használnak. Az HTTP státuszkódot és a JSON tartalmat együttesen kell kiértékelni; egy `ok` mező önmagában nem helyettesíti a hibakezelést. A `POST /api/auth/sso/exchange` tesztelésénél anonimizált értékeket kell használni. Valódi ügyféladatok, éles környezetbeli UUID-k, session tokenek és konkrét időbélyegek nem tartoznak a nyilvános példák közé. Az ismert platform-szintű korlát 2 000 kérés 15 percen belül; eltérő egyedi limit nem igazolt. Nem idempotens POST-hívásokat nem szabad vakon ismételni hálózati megszakadás esetén. A tipikus integrációs hibák ezen az útvonalon a hiányzó kötelező paraméterek, a helytelen adattípusok, a lejárt egyszeri kódok, a nem engedélyezett origók vagy egy nem implementált adatbejegyzés miatt merülnek fel. Az alkalmazásnak ezeket az eseteket külön kell kezelnie, és naplóznia kell a végpont által visszaadott hibaüzenetet, titkos tartalmak rögzítése nélkül. Egy sikeres kérés csak ezt a feldolgozási lépést igazolja, nem feltétlenül egy azt követő e-mail-, fizetési vagy SSO-sikert. Ez közvetlenül releváns a „POST /api/auth/sso/exchange” esetében. A lap technikai ellenőrzése szigorúan a `app/frontend/src/content/api-reference/` alatti Registry-re és a hozzá tartozó backend-útvonalakra támaszkodhat. A élő teszt megjegyzéseknek csak azt kell állítaniuk, amit ténylegesen ellenőriztek. Egy negatív teszt vagy egy kód-analógia nem teljes sikerigazolás. A POST /api/auth/sso/exchange — API-Referenz esetében ezért egyértelműen meg kell különböztetni a dokumentált struktúrát, az automatizált tesztelést és a biztonságosan megfigyelt élő viselkedést.

{"code":"<Egyszeri kód az SSO-visszahívási átirányításból>"}

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