Algolia

    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.

    Type d'autorisation Implicit Grant dans LoadFocus

    Les recommandations de sécurité actuelles (RFC 9700) indiquent que le type Implicit Grant NE DEVRAIT PAS être utilisé. Privilégiez le type Authorization Code avec PKCE.

    Ce que vous saisissez dans LoadFocus

    Dans un test de charge, définissez Type d'autorisation sur OAuth 2.0 et Grant Type sur Implicit. Le formulaire comporte ces champs :

    • Token Name : un libellé pour vous. Il n'est pas envoyé au serveur.
    • Callback URL, Auth URL : le Redirect URI enregistré pour votre client et le point de terminaison d'autorisation du fournisseur.
    • Client ID, Client Secret, Scope, State, Audience : tels que délivrés par votre fournisseur ou convenus avec lui.

    LoadFocus n'ouvre pas de navigateur et n'envoie aucun utilisateur vers l'Auth URL ; il ne peut donc pas réaliser l'étape de redirection dont dépend ce type d'autorisation.

    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é).
    1. 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.
    1. É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.
    1. 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.
    1. 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.
    1. 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.
    1. 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).
    1. Utiliser le token :
    • Joignez le token d'accès aux requêtes API effectuées au serveur de ressources.
    1. Gérer l'expiration du token :
    • Implicit Grant ne renvoie jamais de token de rafraîchissement (RFC 6749, section 4.2.2) : lorsqu'un token d'accès expire, vous devez donc 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 : le serveur d'autorisation ne doit pas en émettre pour ce type d'autorisation, donc tout le flux est répété lorsque le token d'accès expire.

    • À éviter : En raison de ces problèmes de sécurité, le document de bonnes pratiques de sécurité OAuth 2.0 (RFC 9700) indique qu'Implicit Grant NE DEVRAIT PAS être utilisé, et recommande le type 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.

    Précédent
    Type d'autorisation Client Credentials dans OAuth 2.0
    Suivant
    Type d'autorisation Password Credentials dans OAuth 2.0