Type d'autorisation Implicit Grant dans OAuth 2.0

Le type d'autorisation Implicit Grant, egalement connu sous le nom de methode "token", a ete principalement concu pour les applications cote client ou le client ne peut pas stocker un secret client de maniere securisee. Ces applications incluent les applications monopage (SPA) ou d'autres applications basees sur le navigateur. Au lieu de recevoir un code d'autorisation a echanger contre un token d'acces, l'application obtient directement le token d'acces.

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 generalement des parametres de requete tels que client_id, response_type (defini sur "token" pour Implicit Grant), redirect_uri (ou le serveur d'autorisation redirigera apres avoir accorde/refuse l'acces) et scope (indiquant le niveau d'acces demande).

2. Authentification de l'utilisateur :

• L'utilisateur se connecte au serveur d'autorisation (s'il n'est pas deja connecte) et examine la demande d'acces de l'application cliente.

3. Emission du token d'acces :

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

4. Acces a la ressource protegee :

• L'application cliente extrait le token d'acces 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 requetes au serveur de ressources (API) au nom de l'utilisateur.

Comment configurer Implicit Grant ?

1. Enregistrer votre application :

• Commencez par enregistrer votre application aupres du fournisseur OAuth 2.0. Vous recevrez generalement un client_id apres un enregistrement reussi.

2. Configuration du Redirect URI :

• Fournissez un redirect_uri lors de l'enregistrement. Le serveur d'autorisation redirigera les utilisateurs vers cet URI apres qu'ils aient decide d'accorder ou de refuser l'acces. Assurez-vous que cet URI est securise (generalement en utilisant HTTPS) et peut gerer 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 parametres necessaires. Utilisez des bibliotheques ou SDK adaptes au langage ou framework de votre application pour faciliter cela.

4. Extraire et stocker le token :

• Une fois redirige, extrayez le token d'acces du fragment de l'URL. Stockez le token de maniere securisee, en considerant les options de stockage cote client comme le Web Storage (localStorage ou sessionStorage) ou les cookies. Assurez-vous qu'il est protege contre les attaques de cross-site scripting (XSS).

5. Utiliser le token :

• Joignez le token d'acces aux requetes API effectuees au serveur de ressources.

6. Gerer l'expiration du token :

• Puisque Implicit Grant ne fournit generalement pas de tokens de rafraichissement, lorsqu'un token d'acces expire, vous pourriez devoir relancer le flux OAuth pour en obtenir un nouveau.

Considerations :

• Securite : Le type d'autorisation Implicit Grant est considere comme moins securise que le type Authorization Code, notamment parce que le token d'acces est expose dans l'URL. Cela pourrait etre un risque dans les environnements ou les URL peuvent etre journalisees ou accessibles par des tiers.

• Pas de token de rafraichissement : Generalement, Implicit Grant ne fournit pas de tokens de rafraichissement. Ainsi, lorsqu'un token d'acces expire, tout le flux pourrait devoir etre repete.

• Depreciation : En raison de ses problemes de securite inherents, le document de bonnes pratiques de securite OAuth 2.0 recommande d'eviter 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 cote client, ses problemes de securite ont conduit a 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 securisee.