Documentation Index

Fetch the complete documentation index at: https://docs.document360.com/llms.txt

Use this file to discover all available pages before exploring further.

Disclaimer: Dit artikel is gegenereerd door automatische vertaling.

JWT

Prev Next

JSON Web Token (JWT) is een versleuteld tokenformaat dat authenticatie- en autorisatiegegevens veilig tussen twee applicaties overdraagt. In Document360 wordt JWT gebruikt om lezers te authenticeren op je kennisbanksite.

Document360 gebruikt een benadering vergelijkbaar met PKCE (Proof Key for Code Exchange, een veilige OAuth-methode) om het JWT-token te genereren.

Flowchart illustrating user login process for accessing knowledge base content securely.

Wanneer je JWT NIET moet gebruiken

JWT is niet de juiste keuze als:

  • Uw organisatie gebruikt al een gecentraliseerde identiteitsprovider (Okta, Microsoft Entra, Google Workspace) en wil dat lezers via deze authenticatie doen. Gebruik in plaats daarvan SAML of OpenID Connect. Lees hiervoor Single Sign-On (SSO).
  • Je hebt functies nodig zoals het automatisch registreren van SSO-lezers, zelfregistratie van lezers, of het overslaan van de gebruikelijke aanmeldpagina van Document360. Deze functies worden niet ondersteund met JWT.
  • Je hebt gebruikers- (portaal) authenticatie nodig. JWT ondersteunt alleen lezerauthenticatie op de kennisbanksite.

JWT vs SAML vs OpenID Connect

Kenmerk JWT SAML / OpenID Connect
Lezersbeheer Lezers worden geauthenticeerd vanuit je eigen applicatie. Er is geen noodzaak om lezersaccounts aan te maken of te beheren in Document360. Lezers worden beheerd via de Identity Provider (IdP) van uw organisatie, zoals Okta, Azure AD of Google Workspace.
Loginbestemming Ze verwijst altijd door naar de kennisbanksite. Gebruikers kunnen het Document360-portaal niet via JWT bereiken. Kan zowel lezer- als team-inlogs ondersteunen, afhankelijk van de configuratie.
Wanneer te gebruiken Ideaal als je geen IdP hebt, of liever authenticatie in je eigen applicatie beheert. Aanbevolen als je organisatie al een IdP gebruikt en gecentraliseerde authenticatie en toegangscontrole wil.
Gebruikersregistratiestroom Je beheert het inloggen en de gebruikersprovisioning in je eigen app. Kan zelfregistratie, wachtwoordreset en gebruikerslevenscyclusbeheer ondersteunen, afhankelijk van de IdP.
SSO-inlogpagina Je definieert de Aanmeld-URL en optioneel de Uitlog-URL in de JWT-configuratie-instellingen. De inlogpagina wordt beheerd door de IdP, en doorverwijzingen worden beheerd via SAML- of OpenID-instellingen.
Geavanceerde functies Niet ondersteund: SSO-lezers automatisch registreren, de inlogpagina van Document360 overslaan, lezers zelfregistratie. Beschikbaar afhankelijk van de capaciteiten van de IdP.
Implementatie Eenvoudigere opzet voor ontwikkelaars. Je genereert de JWT, ondertekent deze met een clientgeheim dat in Document360 is aangemaakt, en verzorgt de authenticatie in je app. Vereist configuratie van IdP-metadata, certificaten en mappings met Document360.

Hoe JWT-authenticatie werkt

Het onderstaande diagram toont de volledige JWT-authenticatieflow tussen uw applicatie, de Document360-identiteitsserver en de kennisbanksite.

Flowchart illustrating user authentication process with Document360 Identity Server and Customer App.

Belangrijke terminologie

Term Beschrijving
Login-URL Een openbare inlogpagina in je applicatie waar gebruikers worden doorgestuurd om te authenticeren.
Code generatie URL Een beveiligd backend-eindpunt in je app dat gebruikersgegevens naar Document360 stuurt om een autorisatiecode te verkrijgen.
Callback-URL De URL in Document360 waar je app de gebruiker doorverwijst nadat hij de autorisatiecode heeft ontvangen. Dit wordt automatisch gegenereerd door Document360.

Authenticatieflow

  1. De gebruiker krijgt toegang tot de privékennisbank. Document360 detecteert dat JWT SSO is ingeschakeld en verwijst de gebruiker door naar de Aanmeld-URL die in JWT-instellingen is geconfigureerd.
  2. De gebruiker logt in bij je applicatie. Als de gebruiker nog niet geauthenticeerd is, verzorgt je inlogpagina hun authenticatie.
  3. Je backend vraagt om een eenmalige authenticatiecode. Je backend stuurt een POST verzoek naar de Code generatie-URL met de identiteit van de gebruiker, optioneel readerGroupIds, en tokenValidity binnen enkele minuten. Dit verzoek moet worden geautoriseerd met HTTP Basic Auth met uw Client ID en Client Secret.

Voorbeeld autorisatieheader

Authorization: Basic Base64Encode(clientId:clientSecret)

JSON Payload voorbeeld

{
  "username": "firstname + lastname",
  "firstName": "firstname",
  "lastName": "lastname",
  "emailId": "user email",
  "readerGroupIds": ["Obtain from Reader groups overview page in the Document360 portal (Optional)"],
  "tokenValidity": 15
}

OPMERKING

Zorg voor correcte JSON-syntaxis om configuratiefouten te voorkomen.

  1. De Document360 Identity-server geeft een authenticatiecode terug. Als het verzoek geldig is, genereert de identiteitsserver van Document360 een eenmalige autorisatiecode en stuurt deze terug naar je backend.
  2. Je app stuurt de gebruiker terug naar Document360. Je backend voegt de code toe aan de Callback-URL en stuurt de gebruiker ernaartoe. Bijvoorbeeld: https://yourproject.document360.io/jwt/authorize?code=xyz

OPMERKING

De authenticatiecode is een eenmalige gebruikscode en kan niet opnieuw worden gebruikt.

  1. Document360 valideert de code. Document360 stuurt het via backchannel naar de identiteitsserver om het uit te wisselen voor een JWT-token.
  2. Er wordt een lezersessie aangemaakt. Document360 haalt gebruikersinformatie en toegangsregels uit readerGroupIds uit het token. Er wordt een sessie aangemaakt voor de lezer, waardoor hij toegang krijgt tot de toegestane categorieën, talen of versies.

Tokenvaliditeit en sessiegedrag

  • Je kunt de sessieduur definiëren met het tokenValidity veld in de payload (min: 5 minuten, maximaal: 1440 minuten).
  • Zodra het token verloopt, wordt de lezer teruggeleid naar je Login-URL.
  • Als de gebruiker nog steeds geauthenticeerd is in je app, wordt er een nieuwe code gegenereerd en wordt de sessie naadloos opnieuw ingesteld.

Begin met JWT

Artikel Beschrijving
Configureer JWT in Document360 Maak je JWT-configuratie aan, stel inloginstellingen op projectniveau in en genereer je geheime tokens.
Implementeer JWT in je applicatie Stel de backend-redirectlogica in met codevoorbeelden in C#, Node.js en Java.
Test je JWT-configuratie Controleer je setup met cURL of Postman voordat je live gaat.
JWT-configuraties beheren Activeer, deactiveer, verwijder en beheer tokenrotatie, domeinroutering, inlogpagina-statussen en auditlogboeken.
JWT-lezersgroepen Bepaal welke contentlezers kunnen bereiken door deze toe te wijzen aan lezersgroepen via JWT.
Configureer JWT voor de knowledge base-widget Stel JWT-authenticatie in voor je embedded knowledge base-widget.
JWT voor de AI-chatbot Beveilig de toegang van je AI-chatbot met JWT-authenticatie.

TIP

Als je JWT voor het eerst opzet, voltooi dan de stappen in volgorde: Configureer JWT in Document360 → Implementeer JWT in je applicatie → Test je JWT-configuratie.


FAQ

Als een JWT-gebruiker uitlogt bij de clientapplicatie, logt hij dan ook uit bij Document360?

Nee. De sessie op Document360 is onafhankelijk na het eerste aanmelden. Gebruikers kunnen Document360 blijven gebruiken totdat de geldigheid van het token verloopt, zelfs nadat ze zijn uitgelogd bij de clientapplicatie. Als bijvoorbeeld de geldigheid van de token op 1 dag wordt gezet, blijft de Document360-sessie actief totdat de token verloopt.

Kan ik een tokengeldwaarde buiten het toegestane bereik opgeven?

Nee. Als er een waarde buiten het bereik wordt opgegeven, wijst het systeem automatisch de dichtstbijzijnde toegestane waarde toe: 5 minuten voor waarden onder het minimum, en 1440 minuten voor waarden boven het maximum.

Wat is het verschil tussen JWT en SSO?

Je kunt een vergelijking tussen JWT (JSON Web Token) en SSO (Single Sign-On) bekijken in de onderstaande tabel:

Categorie JWT (JSON Web Token) SSO (Single Sign-On)
Authenticatie Tokens die per sessie of gebruikersverzoek worden gegenereerd. Gecentraliseerde authenticatie over apps heen.
Tokenverloop Tokens verlopen meestal na een bepaalde periode. Geen teken; sessie afgehandeld door identiteitsprovider.
Beveiliging Vereist veilige tokenopslag. Veiliger; Gecentraliseerde opslag van inloggegevens.
Gebruik Gebruikt voor stateloze, eenmalige authenticatie. Gebruikt voor meerdere applicaties met één enkele login.
Integratie Makkelijker te implementeren in aangepaste apps. Vereist integratie met een identiteitsprovider.

Kunnen JWT en SSO (SAML of OpenID Connect) tegelijkertijd actief zijn?

Ja. JWT- en SSO-configuraties kunnen zonder conflict in hetzelfde project naast elkaar bestaan. Elk type wordt onafhankelijk beheerd. Wijzigingen aan het ene beïnvloeden het andere niet.

Wat moet ik doen als geheime tokens verloren gaan?

Geheime tokens worden slechts één keer weergegeven bij het maken van de configuratie. Als je het kwijt bent, ga dan naar de configuratiemodus Bewerken en klik op Regenereren voor het relevante token. Regeneratie maakt het bestaande token onmiddellijk ongeldig. Werk je applicatie zonder vertraging bij met het nieuwe token om authenticatiefouten te voorkomen.