Type d'autorisation Implicit Grant dans OAuth 2.0

Le type d'autorisation Implicit Grant, également connu sous le nom de méthode "token", a été principalement conçu pour les applications côté client où le client ne peut pas stocker un secret client de manière sécurisée. Ces applications incluent les applications monopage (SPA) ou d'autres applications basées sur le navigateur. Au lieu de recevoir un code d'autorisation à échanger contre un token d'accès, l'application obtient directement le token d'accès.

Comment fonctionne Implicit Grant ?

1. Redirection :

• L'application cliente redirige l'utilisateur vers le point de terminaison d'autorisation du serveur d'autorisation OAuth 2.0. Cette redirection inclut généralement des paramètres de requête tels que client_id, response_type (défini sur "token" pour Implicit Grant), redirect_uri (où le serveur d'autorisation redirigera après avoir accordé/refusé l'accès) et scope (indiquant le niveau d'accès demandé).

2. Authentification de l'utilisateur :

• L'utilisateur se connecte au serveur d'autorisation (s'il n'est pas déjà connecté) et examine la demande d'accès de l'application cliente.

3. Émission du token d'accès :

• Si l'utilisateur accorde l'accès, le serveur d'autorisation le redirige vers l'application cliente via le redirect_uri fourni. L'URI de redirection inclut le token d'accès (et son expiration) directement dans la partie fragment de l'URL.

4. Accès à la ressource protégée :

• L'application cliente extrait le token d'accès du fragment de l'URL et le stocke (par exemple, dans le stockage local ou une session). Elle utilise ensuite ce token pour effectuer des requêtes au serveur de ressources (API) au nom de l'utilisateur.

Comment configurer Implicit Grant ?

1. Enregistrer votre application :

• Commencez par enregistrer votre application auprès du fournisseur OAuth 2.0. Vous recevrez généralement un client_id après un enregistrement réussi.

2. Configuration du Redirect URI :

• Fournissez un redirect_uri lors de l'enregistrement. Le serveur d'autorisation redirigera les utilisateurs vers cet URI après qu'ils aient décidé d'accorder ou de refuser l'accès. Assurez-vous que cet URI est sécurisé (généralement en utilisant HTTPS) et peut gérer l'extraction du token du fragment de l'URL.

3. Lancer le flux OAuth :

• Redirigez les utilisateurs vers le point de terminaison d'autorisation du serveur d'autorisation avec les paramètres nécessaires. Utilisez des bibliothèques ou SDK adaptés au langage ou framework de votre application pour faciliter cela.

4. Extraire et stocker le token :

• Une fois redirigé, extrayez le token d'accès du fragment de l'URL. Stockez le token de manière sécurisée, en considérant les options de stockage côté client comme le Web Storage (localStorage ou sessionStorage) ou les cookies. Assurez-vous qu'il est protégé contre les attaques de cross-site scripting (XSS).

5. Utiliser le token :

• Joignez le token d'accès aux requêtes API effectuées au serveur de ressources.

6. Gérer l'expiration du token :

• Puisque Implicit Grant ne fournit généralement pas de tokens de rafraîchissement, lorsqu'un token d'accès expire, vous pourriez devoir relancer le flux OAuth pour en obtenir un nouveau.

Considérations :

• Sécurité : Le type d'autorisation Implicit Grant est considéré comme moins sécurisé que le type Authorization Code, notamment parce que le token d'accès est exposé dans l'URL. Cela pourrait être un risque dans les environnements où les URL peuvent être journalisées ou accessibles par des tiers.

• Pas de token de rafraîchissement : Généralement, Implicit Grant ne fournit pas de tokens de rafraîchissement. Ainsi, lorsqu'un token d'accès expire, tout le flux pourrait devoir être répété.

• Dépréciation : En raison de ses problèmes de sécurité inhérents, le document de bonnes pratiques de sécurité OAuth 2.0 recommande d'éviter Implicit Grant en faveur de l'Authorization Code avec PKCE (Proof Key for Code Exchange) pour les clients publics, comme les SPA.

Conclusion :

Bien que le type d'autorisation Implicit Grant offre un flux plus simple pour les applications côté client, ses problèmes de sécurité ont conduit à des recommandations contre son utilisation dans les applications modernes. Si vous construisez de nouvelles applications, en particulier des SPA, envisagez d'utiliser le type Authorization Code avec PKCE pour une approche plus sécurisée.