Guide d'intégration

Ce guide décrit ce que vous devez fournir et mettre en œuvre pour intégrer votre ressource à ProxyNinja : la configuration d’authentification (OIDC, SAML2, CAS3 ou LTI 1.3), le point d’entrée fonctionnel (vérification de session), et des exemples de code par stack (PHP, Laravel, Node), y compris la déconnexion.

OIDC par défaut

Sauf contrainte, choisissez OIDC : c’est le protocole le mieux outillé. SAML2 et CAS3 sont fournis pour les ressources qui ont déjà une brique correspondante. LTI 1.3 est le cas à part : choisissez-le si votre ressource est (ou doit être) un outil LTI lancé depuis un LMS/ENT — voir LTI 1.3.

LTI 1.3 se branche des deux côtés

LTI apparaît deux fois dans ProxyNinja, et ce ne sont pas les mêmes rôles :

• Côté ressource (client) — ProxyNinja est la plateforme LTI, votre ressource est l’outil qu’elle lance. C’est un protocole d’intégration, au même titre qu’OIDC/SAML2/CAS3 → LTI 1.3.
• Côté amont (IDP) — un LMS externe (Brightspace/D2L, Moodle, ENT) est la plateforme LTI et ProxyNinja est l’outil ; le LMS devient alors une source d’identité, comme le GAR ou École Directe → Votre LMS comme source d’identité.

Les deux sont indépendants : vous pouvez être lancé en LTI sans que votre identité vienne d’un LMS, et l’inverse.

Ce que vous fournissez

Élément	OIDC	SAML2	CAS3	LTI 1.3
Identifiant client	client_id + client_secret	entityID du SP + certificat	nom de service	client_id de l’outil (+ clé publique / JWKS si services LTI)
URL de retour	redirect_uri (callback)	ACS (Assertion Consumer Service)	service URL	target_link_uri (URL de lancement)
URL de login (point d’entrée)	✅	✅	✅	✅ initiate_login_uri (initiation OIDC tierce)
URL de logout (back-channel / SLO)	✅	✅	✅	✅ (back-channel OIDC)

Vous fournissez ces éléments pour la préproduction et la production. Voir le questionnaire, sections B et F.

Configuration de l’authentification

Rappel des bases realm (<EDITEUR> = votre realm = le slug de votre tenant) :

Environnement	Modèle de déploiement	Base realm
Préproduction	instance partagée	https://preprod-proxy.gar.ninja/realms/<EDITEUR>
Production	instance dédiée par éditeur	https://<EDITEUR>-auth.proxyninja.fr/realms/<EDITEUR>

Production = une instance ProxyNinja dédiée par éditeur

La production n’est pas un hôte unique. Chaque éditeur dispose de sa propre instance ProxyNinja (Keycloak), à son propre nom d’hôte. Le schéma canonique est https://<EDITEUR>-auth.proxyninja.fr (certains tenants sont sur .gar.ninja) — par ex. ohe-auth.proxyninja.fr, bayard-auth.proxyninja.fr, mediapart-auth.proxyninja.fr, ouiactive-auth.gar.ninja. Le nom d’hôte exact vous est communiqué à l’onboarding. Le realm reste le slug <EDITEUR>, donc l’issuer de production est https://<EDITEUR>-auth.proxyninja.fr/realms/<EDITEUR>.

La préproduction, à l’inverse, est une instance partagée unique (https://preprod-proxy.gar.ninja) qui héberge le realm de chaque éditeur sous /realms/<EDITEUR>.

Dans tous les exemples ci‑dessous, <EDITEUR>-auth.proxyninja.fr est un gabarit : remplacez‑le par l’hôte qui vous est attribué. Et surtout, lisez les endpoints depuis .well-known (découverte OIDC / métadonnées SAML) — ne codez jamais les URLs en dur : seul le nom d’hôte de base change d’un environnement à l’autre.

OIDC (OpenID Connect)

ProxyNinja est l’OP (OpenID Provider). Tout se découvre depuis le document .well-known — ne codez pas les endpoints en dur, lisez-les depuis la découverte.

• Issuer : https://<EDITEUR>-auth.proxyninja.fr/realms/<EDITEUR>
• Découverte : …/realms/<EDITEUR>/.well-known/openid-configuration
• Endpoints (exposés par la découverte) :
  • authorization_endpoint : …/protocol/openid-connect/auth
  • token_endpoint : …/protocol/openid-connect/token
  • userinfo_endpoint : …/protocol/openid-connect/userinfo
  • end_session_endpoint : …/protocol/openid-connect/logout
  • jwks_uri : …/protocol/openid-connect/certs
• Flow : Authorization Code + PKCE (S256).
• Scopes : openid (obligatoire) profile email, plus les scopes d’attributs établissement si activés sur votre realm.
• Authentification client : client_secret_basic (ou client_secret_post).

SAML2

ProxyNinja est l’IdP ; votre application est le SP.

• Métadonnées IdP (à consommer) : https://<EDITEUR>-auth.proxyninja.fr/realms/<EDITEUR>/protocol/saml/descriptor
• SSO / SLO : https://<EDITEUR>-auth.proxyninja.fr/realms/<EDITEUR>/protocol/saml
• À fournir (métadonnées SP) : entityID, URL ACS (binding HTTP-POST), URL SLO, format de NameID souhaité, et le certificat de signature du SP.
• Indiquez si vous exigez des assertions signées/chiffrées (recommandé : assertions signées).

CAS3

ProxyNinja expose le protocole CAS (extension CAS de Keycloak). Vous agissez en client CAS.

• Base CAS : https://<EDITEUR>-auth.proxyninja.fr/realms/<EDITEUR>/protocol/cas
  • login : …/protocol/cas/login?service=<votre-service>
  • validate (CAS3, avec attributs) : …/protocol/cas/p3/serviceValidate
  • logout : …/protocol/cas/logout
• À fournir : l’URL service (votre point d’entrée) et l’URL de logout pour la propagation.

TODO opérateur — endpoints CAS exacts

TODO (en attente de l’opérateur) : confirmer le chemin de base CAS exact exposé par ProxyNinja (…/protocol/cas vs. autre) et la disponibilité de p3/serviceValidate (CAS 3.0, nécessaire pour récupérer les attributs).

LTI 1.3

ProxyNinja est la plateforme LTI (rôle Platform, celui d’un LMS) ; votre ressource est l’outil (rôle Tool). L’utilisateur est authentifié en amont (GAR, ENT…) par ProxyNinja, puis lancé vers votre outil avec un id_token signé qui porte les revendications LTI.

Choisissez LTI 1.3 si votre ressource est déjà un outil LTI (elle est distribuée via Moodle, Brightspace, Canvas…) : vous réutilisez la brique que vous avez, au lieu d’ajouter un client OIDC.

Nous vous fournissons :

• Issuer de la plateforme (iss) : https://<EDITEUR>-auth.proxyninja.fr/realms/<EDITEUR>
• client_id de votre outil et deployment_id (identifiant de déploiement)
• Endpoint d’autorisation (lancement OIDC) : …/realms/<EDITEUR>/protocol/openid-connect/auth
• JWKS de la plateforme (pour valider le id_token de lancement) : …/realms/<EDITEUR>/protocol/openid-connect/certs
• Endpoint de lancement de la plateforme : …/realms/<EDITEUR>/lti-platform/launch

Vous nous fournissez :

• initiate_login_uri — votre endpoint d’initiation OIDC tierce (third-party initiated login), appelé en premier par la plateforme.
• target_link_uri — l’URL de lancement de la ressource (elle doit aussi figurer dans vos redirect URIs valides).
• La clé publique / l’URL JWKS de votre outil, uniquement si vous consommez les services LTI Advantage (voir plus bas) : ils exigent que l’outil signe ses propres jetons client_credentials.

Paramètres du flux (ce sont ceux de la spécification LTI 1.3, pas un choix ProxyNinja) : response_type=id_token, response_mode=form_post, scope=openid, prompt=none, plus les state / nonce que vous devez valider. Côté client Keycloak, cela se traduit par un flux implicite activé et le flux standard désactivé — donc pas d’échange de code ni d’appel /token pour le lancement : tout arrive dans le id_token posté sur votre target_link_uri.

Revendications reçues dans le id_token (préfixe https://purl.imsglobal.org/spec/lti/claim/) :

Revendication	Contenu
message_type · version	LtiResourceLinkRequest · 1.3.0
deployment_id	Le deployment_id que nous vous avons attribué — à vérifier
target_link_uri	L’URL de lancement demandée
roles	Rôles IMS, dérivés de l’attribut GAR profil (voir ci-dessous)
context	Contexte du lancement (id, label, title, type)
resource_link	Lien de ressource (id, title, description)
tool_platform	Identité de la plateforme (name, version, guid, product_family_code)
custom	Paramètres personnalisés autorisés : id_ressource, id_etab, sso_id

Les attributs GAR ne sont pas dans le jeton de lancement

Le lancement LTI porte les revendications LTI ci-dessus, et rien d’autre. Les attributs GAR habituels (NOM, PRE, UAI, PRO, IDO…) n’y figurent pas par défaut : le lancement se fait avec scope=openid seul. Ce qui vous parvient du GAR, c’est le profil traduit en roles et les paramètres custom autorisés (id_ressource, id_etab, sso_id). Si votre ressource a besoin de l’établissement ou du nom, dites-le à l’onboarding : il faut des mappers dédiés sur votre client. Détail : référence des attributs → LTI 1.3.

Rôles. Le profil national GAR est traduit en URI de rôle IMS avant émission — votre outil lit roles, pas profil :

Profil GAR	Rôle LTI
National_1, Enseignant	…/vocab/lis/v2/membership#Instructor
National_2, Eleve	…/vocab/lis/v2/membership#Learner
National_3	…/vocab/lis/v2/membership/Instructor#TeachingAssistant
National_ENTDirecteur	…/vocab/lis/v2/institution/person#Administrator
National_ENTParent	…/vocab/lis/v2/membership#Mentor

Le rôle par défaut, quand le profil est absent ou inconnu, est Learner. Traitez donc roles comme potentiellement dégradé et n’accordez jamais de privilège d’enseignant sur la seule absence de valeur.

Services LTI Advantage exposés par la plateforme (optionnels, activés au cas par cas) :

Service	Endpoint
NRPS (Names and Role Provisioning)	…/realms/<EDITEUR>/lti-services/memberships
AGS (Assignment and Grade Services)	…/realms/<EDITEUR>/lti-services/lineitems
Deep Linking	…/realms/<EDITEUR>/lti-services/deep-linking

Validez le lancement

Un lancement LTI est un POST non authentifié vers votre target_link_uri. Avant de créer la session, votre outil doit : valider la signature du id_token contre le JWKS de la plateforme, vérifier iss, aud (= votre client_id), exp, le nonce (usage unique — rejouez-le et vous acceptez une rediffusion) et le deployment_id. Une bibliothèque LTI 1.3 certifiée fait tout cela pour vous ; un développement maison l’oublie généralement.

TODO opérateur — activation LTI

TODO (en attente de l’opérateur) : confirmer quels realms exposent aujourd’hui le rôle plateforme LTI (préprod / prod), la liste des paramètres custom autorisés par tenant (lti.custom.allowed) et si les services NRPS / AGS / Deep Linking sont ouverts aux éditeurs ou réservés à l’exploitation.

Votre LMS comme source d’identité

Ce cas est l’inverse du précédent et ne change rien à votre intégration : c’est une question de source d’identité, pas de protocole côté ressource.

Quand les utilisateurs n’arrivent pas du GAR mais d’un LMS (Brightspace/D2L, Moodle, ENT compatible LTI), ProxyNinja se déclare comme outil LTI auprès de ce LMS et le rebranche comme fournisseur d’identité du realm — exactement comme il branche le GAR, École Directe ou Pronote. Votre ressource, elle, continue de parler OIDC / SAML2 / CAS3 (ou LTI) sans modification.

À enregistrer dans le LMS (ProxyNinja, côté outil) — <alias> est l’alias de l’IDP, lti13 par défaut :

Élément	Valeur
Login / OIDC initiation URL	https://<EDITEUR>-auth.proxyninja.fr/realms/<EDITEUR>/broker/<alias>/initiate
Redirect / launch URL	https://<EDITEUR>-auth.proxyninja.fr/realms/<EDITEUR>/broker/<alias>/endpoint
Public keyset (JWKS)	https://<EDITEUR>-auth.proxyninja.fr/realms/<EDITEUR>/protocol/openid-connect/certs

À nous transmettre (côté plateforme, fourni par le LMS) : son issuer (iss), son endpoint d’autorisation, son URL JWKS, le client_id qu’il attribue à ProxyNinja et le deployment_id. Brightspace / D2L bénéficie d’un traitement dédié (paramètres d2l_user_id, d2l_org_unit_id, d2l_role).

Attributs réduits

Un LMS n’expose pas le jeu d’attributs GAR. Attendez-vous à une couverture proche d’École Directe — identité et rôle, rarement les structures — et dégradez proprement. Voir la référence des attributs.

Point d’entrée fonctionnel

Le cœur de l’intégration côté éditeur est un point d’entrée qui implémente une seule décision :

Requête entrante sur le point d'entrée
        │
        ▼
Ai-je une session locale valide ?
        │
   ┌────┴─────┐
  OUI         NON
   │           │
   ▼           ▼
Servir la   Demander l'authentification à ProxyNinja
ressource   (OIDC /authorize · SAML AuthnRequest · CAS /login)
                │
                ▼
        Retour (code / ticket) → échange jetons → récupérer les attributs
                │
                ▼
        Créer la session locale → servir la ressource

Comme l’utilisateur arrive déjà authentifié depuis le médiacentre, la demande à ProxyNinja est en général transparente (pas de re-saisie). Voir le parcours de bout en bout.

En LTI 1.3, le point d’entrée est différent

Le schéma ci-dessus vaut pour OIDC / SAML2 / CAS3, où c’est vous qui déclenchez l’authentification. En LTI 1.3, c’est la plateforme qui vous lance : vous exposez deux endpoints (initiate_login_uri puis target_link_uri), et la session locale se crée à partir du id_token posté sur le second. Pas de question « ai-je une session ? » en amont : chaque lancement est une entrée légitime, à valider intégralement. Voir LTI 1.3.

Exemples de code par stack

Bibliothèques recommandées (voir le récapitulatif en bas de page) :

• PHP : jumbojett/openid-connect-php
• Laravel : Socialite + socialiteproviders/keycloak
• Node : openid-client (certifié OpenID)

keycloak-connect est déprécié

L’adaptateur Node keycloak-connect est officiellement déprécié par l’équipe Keycloak au profit de openid-client. Les exemples ci-dessous utilisent donc openid-client. (keycloak-connect reste utilisable pour de l’existant.)

OIDC — point d’entrée + récupération des attributs

PHP

composer require jumbojett/openid-connect-php

<?php
require 'vendor/autoload.php';
use Jumbojett\OpenIDConnectClient;

session_start();

// --- Point d'entrée : ai-je une session locale ? ---
if (!empty($_SESSION['user'])) {
    render_resource($_SESSION['user']);   // OUI → on sert la ressource
    exit;
}

// NON → on demande l'identité à ProxyNinja.
$oidc = new OpenIDConnectClient(
    'https://<EDITEUR>-auth.proxyninja.fr/realms/<EDITEUR>',   // issuer (sans slash final)
    'votre-client-id',
    'votre-client-secret'
);
$oidc->setRedirectURL('https://votre-ressource.fr/callback');
$oidc->addScope(['openid', 'profile', 'email']);
$oidc->setCodeChallengeMethod('S256');             // PKCE recommandé

$oidc->authenticate();                  // redirige vers ProxyNinja, puis revient ici
$claims = $oidc->requestUserInfo();     // récupération des attributs (/userinfo)

$_SESSION['user']          = (array) $claims;
$_SESSION['id_token']      = $oidc->getIdToken();
$_SESSION['access_token']  = $oidc->getAccessToken();

render_resource($_SESSION['user']);

Laravel

composer require socialiteproviders/keycloak

// config/services.php — le provider Keycloak pointe sur votre realm ProxyNinja
'keycloak' => [
    'client_id'     => env('PROXYNINJA_CLIENT_ID'),
    'client_secret' => env('PROXYNINJA_CLIENT_SECRET'),
    'redirect'      => env('PROXYNINJA_REDIRECT_URI'),
    'base_url'      => env('PROXYNINJA_BASE_URL'),  // p.ex. https://<EDITEUR>-auth.proxyninja.fr (hôte communiqué à l'onboarding)
    'realms'        => env('PROXYNINJA_REALM'),     // <EDITEUR>
],

// app/Providers/AppServiceProvider.php (Laravel 11/12) — enregistrer le provider
use Illuminate\Support\Facades\Event;
use SocialiteProviders\Manager\SocialiteWasCalled;

public function boot(): void
{
    Event::listen(function (SocialiteWasCalled $event) {
        $event->extendSocialite('keycloak', \SocialiteProviders\Keycloak\Provider::class);
    });
}

routes/web.php

use Illuminate\Support\Facades\Route;
use Laravel\Socialite\Facades\Socialite;

// --- Point d'entrée : ai-je une session locale ? ---
Route::get('/login', function () {
    if (auth()->check()) {
        return redirect('/');                              // OUI → ressource
    }
    // NON → demander l'identité à ProxyNinja (scope openid obligatoire)
    return Socialite::driver('keycloak')->scopes(['openid', 'profile'])->redirect();
});

Route::get('/callback', function () {
    $gar = Socialite::driver('keycloak')->user();          // attributs + jetons
    $user = User::updateOrCreate(
        ['proxyninja_sub' => $gar->getId()],
        ['name' => $gar->getName(), 'email' => $gar->getEmail()],
    );
    auth()->login($user, remember: true);                  // session locale
    return redirect('/');
});

Node

npm install openid-client express-session

import * as client from 'openid-client';
import express from 'express';
import session from 'express-session';

// Découverte au démarrage (ne codez pas les endpoints en dur)
const issuer = new URL('https://<EDITEUR>-auth.proxyninja.fr/realms/<EDITEUR>');
const config = await client.discovery(issuer, 'votre-client-id', 'votre-client-secret');

const app = express();
app.use(session({ secret: 'changez-moi', resave: false, saveUninitialized: false }));

// --- Point d'entrée : ai-je une session locale ? ---
app.get('/', (req, res) => {
  if (req.session.user) return res.send(`Bonjour ${req.session.user.name}`); // OUI
  res.redirect('/login');                                                    // NON
});

app.get('/login', (req, res) => {
  const code_verifier = client.randomPKCECodeVerifier();
  const state = client.randomState();
  req.session.pkce = { code_verifier, state };
  client.calculatePKCECodeChallenge(code_verifier).then((code_challenge) => {
    const url = client.buildAuthorizationUrl(config, {
      redirect_uri: 'https://votre-ressource.fr/callback',
      scope: 'openid profile email',
      code_challenge,
      code_challenge_method: 'S256',
      state,
    });
    res.redirect(url.href);
  });
});

app.get('/callback', async (req, res) => {
  const currentUrl = new URL(req.originalUrl, 'https://votre-ressource.fr');
  const tokens = await client.authorizationCodeGrant(config, currentUrl, {
    pkceCodeVerifier: req.session.pkce.code_verifier,
    expectedState: req.session.pkce.state,
  });
  const claims = tokens.claims();                                   // claims id_token
  const userinfo = await client.fetchUserInfo(config, tokens.access_token, claims.sub);

  req.session.user = userinfo;                                      // attributs
  req.session.tokens = {
    access_token: tokens.access_token,
    expires_at: Date.now() + (tokens.expires_in ?? 0) * 1000,
  };
  res.redirect('/');                                                // session locale créée
});

app.listen(3000);

Déconnexion (back-channel logout)

ProxyNinja notifie votre ressource lorsqu’une session doit être fermée (POST d’un logout_token JWT). Votre endpoint doit : (1) valider le logout_token (signature via le jwks_uri du realm), (2) extraire sub et/ou sid, (3) détruire la session locale correspondante — en quelques secondes, sans attendre l’expiration d’un jeton.

POST /backchannel_logout HTTP/1.1
Host: votre-ressource.fr
Content-Type: application/x-www-form-urlencoded

logout_token=eyJhbGci....eyJpc3Mi....T3BlbklE..

PHP

<?php
require 'vendor/autoload.php';
use Jumbojett\OpenIDConnectClient;

// Endpoint POST /backchannel_logout
$logoutToken = $_POST['logout_token'] ?? '';

$oidc = new OpenIDConnectClient(
    'https://<EDITEUR>-auth.proxyninja.fr/realms/<EDITEUR>',
    'votre-client-id',
    'votre-client-secret'
);

// Valide la signature + les claims (iss, aud, events, sid/sub) via le JWKS du realm
if ($oidc->verifyLogoutToken($logoutToken)) {
    $sid = $oidc->getSidFromBackChannel();   // ou claim `sub`
    destroy_local_sessions_for($sid);        // votre logique (table sid → session)
    http_response_code(200);
} else {
    http_response_code(400);
}

Laravel

// routes/web.php — endpoint public (CSRF exempté)
use Jumbojett\OpenIDConnectClient;

Route::post('/backchannel-logout', function (\Illuminate\Http\Request $request) {
    $oidc = new OpenIDConnectClient(
        config('services.keycloak.base_url').'/realms/'.config('services.keycloak.realms'),
        config('services.keycloak.client_id'),
        config('services.keycloak.client_secret'),
    );
    if (! $oidc->verifyLogoutToken($request->input('logout_token'))) {
        abort(400);
    }
    $sid = $oidc->getSidFromBackChannel();
    // Invalider la/les session(s) Laravel associées à ce sid (table de correspondance)
    \DB::table('sessions')->where('pn_sid', $sid)->delete();
    return response()->noContent();
})->withoutMiddleware(\Illuminate\Foundation\Http\Middleware\VerifyCsrfToken::class);

Node

import express from 'express';
import * as jose from 'jose';

// JWKS du realm pour vérifier la signature du logout_token
const JWKS = jose.createRemoteJWKSet(
  new URL('https://<EDITEUR>-auth.proxyninja.fr/realms/<EDITEUR>/protocol/openid-connect/certs'),
);

app.post('/backchannel-logout', express.urlencoded({ extended: false }), async (req, res) => {
  try {
    const { payload } = await jose.jwtVerify(req.body.logout_token, JWKS, {
      issuer: 'https://<EDITEUR>-auth.proxyninja.fr/realms/<EDITEUR>',
      audience: 'votre-client-id',
    });
    // Vérifier l'event de logout puis détruire la session liée à sid/sub
    if (!payload.events?.['http://schemas.openid.net/event/backchannel-logout']) {
      return res.sendStatus(400);
    }
    await destroySessionsFor(payload.sid ?? payload.sub); // votre store de sessions
    res.sendStatus(200);
  } catch {
    res.sendStatus(400);
  }
});

Cartographie sid → session

Pour pouvoir fermer la bonne session, stockez le sid (claim de l’id_token) au moment de la connexion, en l’associant à votre identifiant de session local.

Durée de session

La session applicative correspond à la durée de l’access_token : une fois l’utilisateur authentifié, servez la ressource pendant la durée du jeton.

Bibliothèques recommandées (récapitulatif)

Protocole	PHP	Laravel	Node.js
OIDC	jumbojett/openid-connect-php	Socialite + socialiteproviders/keycloak (ou Kovah/laravel-socialite-oidc)	openid-client (+ openid-client/passport)
SAML2	onelogin/php-saml (ou simpleSAMLphp en mode SP)	aacotroneo/laravel-saml2 (basé sur OneLogin)	@node-saml/passport-saml (ou samlify)
CAS3	apereo/phpCAS	apereo/phpCAS (intégré manuellement)	connect-cas2 / client CAS dédié
LTI 1.3	packbackbooks/lti-1p3-tool (ou celtic-lti/lti)	packbackbooks/lti-1p3-tool (intégré manuellement)	ltijs

TODO opérateur — bibliothèques LTI

TODO (en attente de l’opérateur) : les bibliothèques LTI ci-dessus sont des suggestions à valider — aucune n’est aujourd’hui utilisée par un éditeur intégré à ProxyNinja. Exigence réelle : une implémentation LTI 1.3 Advantage Tool qui valide signature, nonce et deployment_id. Confirmez celle que nous recommandons officiellement avant publication auprès des éditeurs.

Mécanisme conseillé : middleware

Un middleware prêt à l’emploi (les bibliothèques ci-dessus) est plus rapide et plus sûr qu’un développement maison. Réservez le code spécifique au point d’entrée (vérification de session) et au mapping des attributs.

Bibliothèques officielles Keycloak

En complément des bibliothèques à l’état de l’art ci‑dessus, Keycloak publie ses propres bibliothèques officielles (outillage maintenu par l’équipe Keycloak) :

• Vue d’ensemble : Securing applications and services
• JavaScript / SPA : keycloak-js — adaptateur JavaScript
• Node.js : adaptateur Node.js (officiellement déprécié — privilégiez openid-client)

Bonnes pratiques

1. Stockage sécurisé des jetons : jamais en clair ; cookies de session serveur (HttpOnly, Secure, SameSite) ou store serveur.
2. PKCE (S256) systématique sur le flow OIDC Authorization Code.
3. Découverte .well-known : lisez les endpoints depuis la découverte, ne les codez pas en dur.
4. Déconnexion en quelques secondes : propagez le back-channel logout immédiatement ; n’attendez jamais l’expiration d’un jeton.
5. Validez toujours la signature des jetons (id_token, logout_token) via le jwks_uri du realm — et, en LTI 1.3, également le nonce (usage unique) et le deployment_id.

La suite

• Quels attributs allez-vous recevoir ? → Référence des attributs GAR
• Besoin d’une recommandation pour votre cas ? → Questionnaire