JWT

JSON Web Token (JWT) est un format de jeton chiffré qui transfère de manière sécurisée les données d’authentification et d’autorisation entre deux applications. Dans Document360, JWT est utilisé pour authentifier les connexions des lecteurs à votre site de base de connaissances.

Document360 utilise une approche similaire à PKCE (Proof Key for Code Exchange, une méthode OAuth sécurisée) pour générer le jeton JWT.

Quand NE PAS utiliser JWT

JWT n’est pas le bon choix si :

• Votre organisation utilise déjà un fournisseur d’identité centralisé (Okta, Microsoft Entra, Google Workspace) et souhaite que les lecteurs s’authentifient via celui-ci. Utilisez plutôt SAML ou OpenID Connect. Pour ce faire, lisez Connexion Unique (SSO).
• Vous avez besoin de fonctionnalités telles que des lecteurs SSO à enregistrement automatique, l’auto-enregistrement du lecteur, ou le fait de sauter la page de connexion commune de Document360. Ces fonctionnalités ne sont pas prises en charge par JWT.
• Vous avez besoin d’une authentification utilisateur (portail). JWT ne prend en charge que l’authentification par lecteur sur le site de la base de connaissances.

JWT vs SAML vs OpenID Connect

Fonctionnement de l’authentification JWT

Le schéma ci-dessous montre le flux complet d’authentification JWT entre votre application, le serveur d’identité Document360 et le site de la base de connaissances.

Terminologie clé

Flux d’authentification

1. L’utilisateur accède à la base de connaissances privée. Document360 détecte que JWT SSO est activé et redirige l’utilisateur vers l’URL de connexion configurée dans les paramètres JWT.
2. L’utilisateur se connecte à votre application. Si l’utilisateur n’est pas encore authentifié, votre page de connexion gère son authentification.
3. Votre backend demande un code d’authentification à usage unique. Votre backend envoie une POST requête à l’URL de génération de code avec l’identité de l’utilisateur, optionnelle readerGroupIds, et tokenValidity en quelques minutes. Cette requête doit être autorisée en utilisant l’authentification HTTP Basic avec votre identifiant client et votre secret client.

Exemple d’en-tête d’autorisation

Authorization: Basic Base64Encode(clientId:clientSecret)

Exemple de charge utile JSON

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

4. Le serveur d’identité Document360 renvoie un code d’authentification. Si la requête est valide, le serveur d’identité de Document360 génère un code d’autorisation à usage unique et le renvoie à votre backend.
5. Votre application redirige l’utilisateur vers Document360. Votre backend ajoute le code à l’URL de rappel et y redirige l’utilisateur. Par exemple : https://yourproject.document360.io/jwt/authorize?code=xyz

6. Document360 valide le code. Document360 l’envoie au serveur d’identité via un backchannel pour l’échanger contre un jeton JWT.
7. La session de lecture est créée. Document360 extrait les informations utilisateur et les règles d’accès à partir readerGroupIds du jeton. Une session est créée pour le lecteur, lui donnant accès aux catégories, langues ou versions autorisées.

Validité du jeton et comportement de session

• Vous pouvez définir la durée de la session en utilisant le tokenValidity champ dans la charge utile (min : 5 minutes, maximum : 1440 minutes).
• Une fois le jeton expiré, le lecteur est redirigé vers votre URL de connexion.
• Si l’utilisateur est toujours authentifié dans votre application, un nouveau code est généré et la session est rétablie sans interruption.

Commencez avec JWT

FAQ