Implémenter OAuth2 dans Symfony : guide pour sécuriser vos API

Bonjour tout le monde, merci d’avoir cliqué sur cet article ! 😊

Aujourd’hui on va parler sécurité et authentification.

C’est quoi OAuth2 ?

Dans la vie et plus particulièrement sur le web on s’authentifie généralement avec un email et un mot de passe. Mais ce n’est pas toujours le cas notamment lorsque l’on doit se connecter à un service tiers ou une API.

Si c’est votre cas vous allez probablement rencontrer un type de protocole appelé OAuth2.

”C’est quoi ce machin ?”

Si vous avez déjà eu à créer des API vous avez sans doute manipulé des JWT ou JSON Web Token dont le principe est de créer un jeton à chaque utilisateur qui se connecte afin d’authentifier chacune de ses futures requêtes API. 😛

Avec OAuth2, ce principe n’est pas si différent qu’il n’y paraît. Déjà, il utilise également des tokens et on peut également se connecter avec un identifiant et un mot de passe classiques pour l’obtenir.

Installation

Pour utiliser OAuth2 dans Symfony nous allons passer par un bundle dédié que vous pouvez installer avec :

composer-install-oauth2-server.sh 44 B

1

composer require league/oauth2-server-bundle

Se connecter avec un identifiant/mot de passe

Une fois ce bundle installé, on va pouvoir mettre en place le système d’authentification de Symfony par défaut dont la documentation se trouve ici

Une fois cela fait, nous aurons des utilisateurs en base de données pouvant se connecter de façon standard sur un formulaire de login.

Une fois que vous avez un utilisateur et ses identifiants vous pouvez créer un client pour notre authentification OAuth2 avec cette commande :

php-create-league-oauth2-client.sh 55 B

1

php bin/console league:oauth2-server:create-client test

Vous retrouverez ensuite ce client dans la table oauth2_client de la base de données et la console va vous réveler un identifiant ainsi qu’un secret. Conservez ces deux valeurs nous allons les réutiliser.

A ce stade vous avez donc un client oauth2 exploitable et qui fonctionne par “client_credentials” c’est à dire par identifiant et mot de passe.
Pour l’utiliser vous devez créer une requête POST sur la route /oauth2/token et passer en contenu un JSON de ce type :

post-oauth.json 296 B

1 2 3 4 5 6 7

{
	"grant_type": "client_credentials",
	"client_id": "066f283d2b13c34ad9c191aafb5a3bdb",
	"client_secret": "578be0932af10df46f94b6b3b80e74113deac3886a5c12024173a8514eeddc18992343dfc63d4fb391c011f64e35d645ac0f45425ea133965af41e2263cedd91",
	"username": "test@test.com",
	"password": "test"
}

• grant_type spécifiant quel type d’authentification nous souhaitons réaliser
• client_id et client_secret correspondant aux valeurs créées par le bundle précédemment
• username et password correspondant aux identifiants de votre utilisateur déjà créé

Si tout se passe bien, cette requête doit vous retourner un token Bearer valide sous cette forme :

oauth-response.json 804 B

1 2 3 4 5

{
	"token_type": "Bearer",
	"expires_in": 3600,
	"access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJhdWQiOiIwNjZmMjgzZDJiMTNjMzRhZDljMTkxYWFmYjVhM2JkYiIsImp0aSI6IjNhMGZkZTk4MGY1YWI3YTA0YWFhNjA4Yjc1MTk2MjM1OTJkMTdjMmFlMWVhZGQzNWY2YWE4OWMyN2IwMWQxMGVlNTA1MzYwN2ZjOWMwNzZlIiwiaWF0IjoxNzQ0MTEzOTQxLjUzMzg0NSwibmJmIjoxNzQ0MTEzOTQxLjUzMzg0OSwiZXhwIjoxNzQ0MTE3NTQxLjUyNjI4Mywic3ViIjoiMDY2ZjI4M2QyYjEzYzM0YWQ5YzE5MWFhZmI1YTNiZGIiLCJzY29wZXMiOlsiZW1haWwiXX0.li7qKBD32o3kvg1VCBrWp8_0mws5naUZ4jb-RqnLpFkArCZ3hIfG5YOwbT3IdrmsamEhPHoMcWvAz9zj4yH7nc11fJhO-avMstpqGaHnz4DWrWlzOXkeC7-VhOJVnQT_dTFrkhQkRuSwjMJQAtctfAh3z3tZWgbv90loRIFgkFTY2LNnJcZUJzNUWSaf2rkiG42gd-8186PCppp9QLzgyeO4fp4G-n6OQ7HHw2wHWkQqPDifSX-iHtbUyA2M4Vq0Owxtv--dFMITiwaRBrsa2Tn0-sLBWOt2D0ubD-dfq4gKtbTPIG4g5_2C-1rOv-frWBxVsz6dHkKYIRkWv_bssw"
}

Se connecter avec le consentement de l’utilisateur

L’une des méthodes courantes d’utilisation d’OAuth2 est que l’utilisateur lui-même puisse valider sa connexion à un service tiers.

Par exemple vous souhaitez vous connecter sur un site via votre compte Facebook, vous cliquez sur le bouton bleu, Facebook vous demande votre autorisation et si vous la validez vous êtes connecté sur le site en question. C’est de l’OAuth2. 🪄

Pour mettre en place cette méthode, il va nous falloir un élément en plus qui est une URL de redirection. Lorsque votre utilisateur aura donné son accord pour se connecter, il sera redirigé vers cette URL pour continuer sa navigation.
Vous pouvez donc ajouter dans un controller une route de ce type :

Maintenant, nous allons mettre à jour le client oauth2 que nous avons crée dans la base de données lors de la première partie de cet article. Pour ce faire il existe une commande directement dans le bundle :

leauge-update-client.sh 142 B

1

php bin/console league:oauth2-server:update-client test --add-redirect-uri=https://localhost:8000/callback --add-grant-type=authorization_code

Grâce à cette commande, nous avons maintenant défini que notre authentification devait fonctionner avec un code d’autorisation ainsi qu’une URL de redirection.

Pour tester cette partie vous pouvez faire une requête GET cette fois, vers la route suivante :

url-test.txt 153 B

1

https://127.0.0.1:8000/authorize?response_type=code&client_id=2383afb8cbd7dcf938ca1ecabf84c1a3&redirect_uri=https://localhost:8004/callback&scope=email

Décomposons un peu les paramètres de cette route :

• response_type signifie que nous souhaitons récupérer un code unique à la suite de cette requête afin de l’envoyer dans notre requête POST vers /oauth2/token et obtenir notre token
• client_id correspond toujours au client enregistré dans la base de données
• redirect_url est l’URL de redirection que nous avons définie
• scope est établi par défaut sur email par le bundle

Si vous testez cette route directement vous devriez avoir une erreur précisant qu’elle doit être atteinte par un utilisateur déjà connecté.

Ce qui est logique car il doit nous donner son accord donc on doit le connecter auparavant. 😛

Via la route /login entrez les identifiants de l’utilisateur enregistré et connectez-vous.

Bon, maintenant il nous manque encore une étape, celle d’avoir une page avec un bouton permettant d’autoriser la connexion ou non.

Ajoutons donc cette route dans un controller :

Ici nous écrivons notre url avec ses paramètres vers laquelle l’utilisateur va être envoyé si jamais il autorise la connexion.
Dans un twig on affiche donc un formulaire basique :

Ainsi l’utilisateur va pouvoir donner son consentement via la page web directement.

“Ok super tout est prêt ! On va tester ?”

Tout ? Non, pas tout à fait. Il reste encore une étape à écrire qui va nous permettre de soit valider le consentement de l’utilisateur soit le rediriger vers la page de consentement.

Pour cela on va créer un EventSubscriber permettant d’écouter l’événément AUTHORIZATION_REQUEST_RESOLVE

Si la requête est en POST c’est que le formulaire a été soumis et validé donc on peut authentifier notre utilisateur, sinon on le renvoie vers notre route dernièrement créée. 😊

Lorsque vous validez le formulaire vous êtes maintenant redirigé vers une URL du type

call-back-url.txt 42 B

1

https://127.0.0.1:8000/callback?code=XXXXX

Ce code en paramètre peut maintenant être utilisé dans la requête POST vers oauth2/token avec le contenu suivant :

authentication.json 315 B

1 2 3 4 5 6 7

{
	"grant_type": "authorization_code",
	"client_id": "2383afb8cbd7dcf938ca1ecabf84c1a3",
	"client_secret": "49a819496c3c4892d1614ff4437d84c9dcfcae9f6c622198b8f52926dad8a5d5972ce295d38a47bbbf16f03a9da5d5fde51c6ce54bc07237354db8c61916eca5",
	"redirect_uri": "https://127.0.0.1:8000/callback",
	"code": "XXXXX"
}

Comme précédémment avec la connexion via utilisateur/mot de passe, vous obtenez un token utilisable. 😄

Conclusion

Voilà vous savez désormais comment implémenter un système d’authentification basé sur OAuth2 et vous voyez également comment cela se passe “de l’autre côté” lorsque vous autorisez votre compte Facebook, Google, etc à se connecter à un site ou une application tiers.

Je vous dis à une prochaine pour de nouvelles techniques passionnantes 😊