POST/api/auth/sso/exchange

Lescht Schrëtt vun engem SSO Login (SAML/OIDC): Ännerung vum Callback-Einmalcode fir e reguläre Session-JWT.

D'Säit „POST /api/auth/sso/exchange — API-Referenz“ behandelt de Funktiounsberäich, deen an der URL genannt gëtt. Den existente Inhalt gëtt ëm den tatsächleche Oflaf, d'Viraussetzungen an déi bekannt Grenze ergänzt. Zentor huet kee Entwéckler-API-Key-System. Fir d'Dashboard ginn Session-JWTs mat zwielef Stonne Laafzäit a Refresh-Tokens mat siwe Deeg Laafzäit benotzt; TOTP a SSO si fakultativ. Widget-Embed-Tokens ginn eemol am Klartext ugewisen a sinn u zougelossen Origins gebonnen. D'Dokumentatioun zu `POST /api/auth/sso/exchange` soll verbindlech als technesch Beschreiwung vun dësem konkreten Endpunkt gelies ginn. Entscheedend sinn Method, Wee, Authentifizéierung, Flichtfelder, méiglech Feeler an d'Fro, ob en erneite Opruff dee selwechten Effekt auslöst. Dëse Hëllefsofsatz https://zentor-app.de/hilfe/api-referenz/auth/auth.sso_exchange dierf dofir keng allgemeng Reklammausoen enthalen, mä nëmmen nozvollzéibar Integratiounsschrëtt a beluechten Äntwertbeispiller. Fir en Opruff vun `/api/auth/sso/exchange` gëtt d'Ufro entspriechend der Registry opgebaut. Ëffentlech Routen brauchen keen allgemengen Entwéckler-API-Schlëssel, well Zentor keen esou Schlësselsystem ubitt. Geschützte Widget-Routen benotzen dogéint den eemol ugewisenen Embed-Token an eng Origin-Préiwung. Den HTTP-Status an den JSON-Inhalt mussen zesumme ausgewäert ginn; e `ok`-Feld eleng ersetzt keng Feelerbehandlung. Beim Test vun `POST /api/auth/sso/exchange` sinn anonymiséiert Wäerter ze benotzen. Reell Kundendaten, produktiv UUIDs, Sitzungs-Tokens a konkret Zäitstempele gehéieren net an ëffentlech Beispiller. De bekannte plattformwäite Grenzwäert läit bei 2.000 Ufroen bannent 15 Minutten; e ofweichend Eenzellimit ass net beluecht. Net idempotent POST-Opruff dierfen no engem onkloren Netzwierkofbroch net blann widderholl ginn. Typesch Integratiounsfeeler fir dës Rout entstinn duerch feelend Flichtparameter, falsch Datentypen, ofgelafen Eemolcoden, net erlaabt Origins oder e net implementéierte Datesaz. D'Applikatioun sollt esou Fäll getrennt behandelen an déi vum Endpunkt zréckgeliwwert Feelermeldung protokolléieren, ouni geheim Inhalter matzeschreiwen. En erfollegräiche Request bestätegt nëmmen dëse Verschaffungsschrëtt, net automatesch en uschléissend ugelagerten E-Mail-, Bezuel- oder SSO-Erfolleg. Dëst ass fir „POST /api/auth/sso/exchange“ direkt relevant. D'technesch Iwwerpréiwung vun dëser Säit muss sech zwéngend op d'Registry ënner `app/frontend/src/content/api-reference/` an déi zougehéiereg Backend-Routen stëtzen. Live-Test-Vermierker dierfen nëmmen dat behaapten, wat tatsächlech gepréift gouf. En Negativtest oder eng Code-Analogie ass kee vollstännege Erfollegsnowäis. Fir POST /api/auth/sso/exchange — API-Referenz ass dofir kloer tëscht dokumentéierter Struktur, automatiséiertem Test a sécher beobachtetem Live-Verhalen ze ënnerscheeden.

Auth & Absicherung

Keine Authentifizierung erforderlich

Idempotent: Nein

Parameter

code(body, string, erforderlich)Eenzeg Ersatzcode vum SSO-Redirekt

Beispiel-Request

{"code":"<Een-Zäit-Code aus dem SSO-Callback-Redirect>"}

Beispiel-Response

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

Fehlercodes

400 SSO_EXCHANGE_INVALIDDe Retourcode ass net gülteg, scho benotzt oder ass ofgelaf.

Live-Test-Nachweis

Negativ Fall (400) mat erfindleche Code live verifizéiert; Succèsfall géif e komplette SAML/OIDC Redirect duerchféieren mat echtem Identitéitsprovider erfuerderen, net an dësem Testumfeld replikéiert.

Authentifizéierung