Pare-feu sans état Symfony : authentifier une API par jeton d'accès
Un pare-feu sans état dans Symfony authentifie chaque requête d'API par un jeton d'accès, sans session ni cookie : le jeton accompagne chaque appel.
final class SceauHandler implements AccessTokenHandlerInterface { public function __construct(private readonly GuildeRepository $guildeRepository) { } public function getUserBadgeFrom(#[\SensitiveParameter] string $accessToken): UserBadge { $guilde = $this->guildeRepository->findOneBy(['sceau' => $accessToken]) ?? throw new BadCredentialsException('Aucune guilde ne porte ce sceau.'); return new UserBadge($guilde->getUserIdentifier(), static fn () => $guilde); } } // security.yaml : api: { pattern: ^/api, stateless: true, access_token: { token_handler: App\Security\SceauHandler } }
Un client d'API ne garde pas de cookie de session. Avec stateless: true et access_token, Symfony lit l'en-tête Authorization: Bearer …, le confie au handler, qui renvoie un UserBadge ou refuse le jeton : la réponse est alors un 401. Aucune session n'est ouverte, et celle d'un employé connecté au site ne donne aucun droit sur l'API. Le piège : l'ordre des pare-feux. Symfony n'en retient qu'un, le premier dont le pattern correspond ; déclaré après main, qui n'a pas de motif, le pare-feu api ne voit jamais passer une requête, et le client reçoit une redirection vers la page de connexion.
Les exercices font remettre un sceau à chaque guilde pour réserver une table, retrouver la guilde qui le porte et lui rattacher la réservation, puis ouvrir aux guildes l'inscription aux soirées de contes, refusée en 401 sans sceau valide.
2 exercices font travailler cette notion, en écrivant du code dans le navigateur.
Dans les parcours
- Le sceau de la guilde Symfony pour les devs PHP · chapitre 5 : Les parchemins magiques
- Les guildes s'invitent Symfony pour les devs PHP · chapitre 12 : Le grand service