Protected App — Intégration d’authentification sans SDK

Le Protected App est conçu pour éliminer la complexité des intégrations SDK en séparant la couche d’authentification de votre application. Nous gérons l’authentification, vous permettant de vous concentrer sur votre fonctionnalité principale. Une fois l’utilisateur authentifié, le Protected App sert le contenu depuis votre serveur.

Fonctionnement du Protected App

Le Protected App, propulsé par Cloudflare, fonctionne globalement sur des réseaux edge, garantissant une faible latence et une haute disponibilité pour votre application.

Le Protected App maintient l’état de session et les informations utilisateur. Si un utilisateur n’est pas authentifié, le Protected App le redirige vers la page de connexion. Une fois authentifié, le Protected App encapsule la requête de l’utilisateur avec les informations d’authentification et d’utilisateur, puis la transmet au serveur d’origine.

Ce processus est visualisé dans le diagramme de flux suivant :

Protéger votre serveur d’origine

Le serveur d’origine, qui peut être un appareil physique ou virtuel non détenu par le Protected App de Logto, est l’endroit où réside le contenu de votre application. À l’instar d’un serveur de Content Delivery Network (CDN), le Protected App gère les processus d’authentification et récupère le contenu depuis votre serveur d’origine. Par conséquent, si des utilisateurs accèdent directement à votre serveur d’origine, ils peuvent contourner l’authentification et votre application n’est plus protégée.

Il est donc important de sécuriser les connexions à l’origine, cela empêche les attaquants de découvrir et d’accéder à votre serveur d’origine sans authentification. Il existe plusieurs façons de le faire :

1. Validation d’en-tête HTTP
2. Validation de JSON Web Tokens (JWT)

Validation d’en-tête HTTP

Sécuriser votre serveur d’origine peut se faire en utilisant l’authentification HTTP Basic.

Chaque requête provenant du Protected App inclut l’en-tête suivant :

Authorization: Basic base64(appId:appSecret)

En validant cet en-tête, vous pouvez confirmer que la requête provient du Protected App et refuser toute requête ne comportant pas cet en-tête.

Si vous utilisez Nginx ou Apache, vous pouvez consulter les guides suivants pour mettre en place l’authentification HTTP Basic sur votre serveur d’origine :

1. Nginx : Configurer l’authentification HTTP Basic
2. Apache : Authentification et Autorisation

Pour vérifier les en-têtes dans votre application, consultez l’exemple d’authentification HTTP Basic fourni par Cloudflare pour apprendre à restreindre l’accès à l’aide du schéma HTTP Basic.

Validation de JSON Web Tokens (JWT)

Une autre façon de sécuriser votre serveur d’origine est d’utiliser des JSON Web Tokens (JWT).

Chaque requête authentifiée provenant du Protected App inclut l’en-tête suivant :

Logto-ID-Token: <JWT>

Le JWT est appelé Jeton d’identifiant (ID Token) qui est signé par Logto et contient des informations utilisateur. En validant ce JWT, vous pouvez confirmer que la requête provient du Protected App et refuser toute requête ne comportant pas cet en-tête.

Le jeton est chiffré et signé en tant que jeton JWS.

Les étapes de validation :

1. Valider un JWT
2. Valider la signature JWS
3. L’émetteur du jeton est https://<your-logto-domain>/oidc (émis par votre serveur d’auth Logto)

const express = require('express');
const jwksClient = require('jwks-rsa');
const jwt = require('jsonwebtoken');

const ISSUER = 'https://<your-logto-domain>/oidc';
const CERTS_URL = 'https://<your-logto-domain>/oidc/jwks';

const client = jwksClient({
  jwksUri: CERTS_URL,
});

const getKey = (header, callback) => {
  client.getSigningKey(header.kid, function (err, key) {
    callback(err, key?.getPublicKey());
  });
};

const verifyToken = (req, res, next) => {
  const token = req.headers['Logto-ID-Token'];

  // Assurez-vous que la requête entrante contient notre en-tête de jeton
  if (!token) {
    return res
      .status(403)
      .send({ status: false, message: 'en-tête Logto-ID-Token requis manquant' });
  }

  jwt.verify(token, getKey, { issuer: ISSUER }, (err, decoded) => {
    if (err) {
      return res.status(403).send({ status: false, message: 'jeton id invalide' });
    }

    req.user = decoded;
    next();
  });
};

const app = express();

app.use(verifyToken);

app.get('/', (req, res) => {
  res.send('Bonjour le monde !');
});

app.listen(3000);

Obtenir l’état d’authentification et les informations utilisateur

Si vous avez besoin d’obtenir l’état d’authentification et les informations utilisateur pour votre application, vous pouvez également utiliser l’en-tête Logto-ID-Token.

Si vous souhaitez simplement décoder le jeton, vous pouvez utiliser le code suivant :

const express = require('express');

const decodeIdToken = (req, res, next) => {
  const token = req.headers['Logto-ID-Token'];

  if (!token) {
    return res.status(403).send({
      status: false,
      message: 'en-tête Logto-ID-Token requis manquant',
    });
  }

  const parts = token.split('.');
  if (parts.length !== 3) {
    throw new Error('Jeton d’identifiant invalide');
  }

  const payload = parts[1];
  const decodedPayload = atob(payload.replace(/-/g, '+').replace(/_/g, '/'));
  const claims = JSON.parse(decodedPayload);

  req.user = claims;
  next();
};

const app = express();

app.use(decodeIdToken);

app.get('/', (req, res) => {
  res.json(req.user);
});

app.listen(3000);

Personnaliser les revendications du jeton d’identifiant

Par défaut, l’en-tête Logto-ID-Token inclut les revendications OIDC standard (par exemple sub, name et email). Pour inclure des revendications étendues telles que les rôles ou les données d’organisation, les deux éléments suivants doivent être configurés :

1. Bascule du locataire : Activez la revendication dans Console > Custom JWT > Jeton d’identifiant.
2. Scopes du Protected App : Dans les paramètres de votre Protected App, sélectionnez la portée correspondante sous Revendications du jeton d’identifiant > Scopes supplémentaires.

Les revendications étendues sont incluses dans le jeton d’identifiant transmis uniquement lorsque la revendication est activée dans Custom JWT et que la portée correspondante est sélectionnée pour le Protected App. Voir Jeton d’identifiant personnalisé pour la liste complète des scopes et revendications étendus.

Portée	Revendications
custom_data	custom_data
identities	identities, sso_identities
roles	roles
urn:logto:scope:organizations	organizations, organization_data
urn:logto:scope:organization_roles	organization_roles

Obtenir l’hôte d’origine

Si vous avez besoin d’obtenir l’hôte d’origine demandé par le client, vous pouvez utiliser l’en-tête Logto-Host ou x-forwarded-host.

Personnaliser les règles d’authentification

Par défaut, le Protected App protège toutes les routes. Si vous souhaitez personnaliser les règles d’authentification, vous pouvez définir le champ "Règles d’authentification personnalisées" dans la Console.

Les expressions régulières sont prises en charge, voici deux scénarios d’exemple :

1. Pour ne protéger que les routes /admin et /privacy avec authentification : ^/(admin|privacy)/.*
2. Pour exclure les images JPG de l’authentification : ^(?!.*\.jpg$).*$

Développement local

Le Protected App est conçu pour fonctionner avec votre serveur d’origine. Cependant, si votre serveur d’origine n’est pas accessible publiquement, vous pouvez utiliser un outil comme ngrok ou Cloudflare Tunnels pour exposer votre serveur local à Internet.

Transition vers une intégration SDK

Le Protected App est conçu pour simplifier le processus d’authentification. Cependant, si vous décidez de passer à une intégration SDK pour un meilleur contrôle et une personnalisation accrue, vous pouvez créer une nouvelle application dans Logto et configurer l’intégration SDK. Pour une transition en douceur, vous pouvez réutiliser les configurations d’application du Protected App. Le Protected App est en réalité une "Application Web Traditionnelle" dans Logto, vous pouvez trouver l’"AppId" et l’"AppSecret" dans les paramètres de l’application. Une fois la transition terminée, vous pouvez retirer le Protected App de votre application.

Ressources associées

Protected App : Construisez l’authentification de votre application en quelques clics. Aucun code requis.

La motivation derrière Protected App

La manière la plus rapide de construire un système d’authentification