Qu'est-ce que OAuth ?

Créer de nouveaux comptes pour tous les différents sites web a toujours été une tâche fastidieuse. La plupart d'entre eux sont des travaux redondants, car ils contiennent tous les mêmes informations utilisateur, telles que le nom et le numéro de téléphone.

"Est-il possible de permettre à une application d'accéder à mes données sans nécessairement lui donner mon mot de passe ?"

OAuth est une norme qui tente de résoudre ce problème en fournissant une autorisation centralisée.

OAuth, qui signifie "Open Authorization", est une norme ouverte pour la délégation d'accès. Il vous permet (propriétaires de ressources) de partager des informations entre applications et sites web sans exposer vos mots de passe. Il est largement utilisé, et vous utilisez probablement des services OAuth quotidiennement. Par exemple, pour vous connecter à GeeksforGeek, vous pouvez choisir de vous connecter en utilisant votre compte Google. Ce faisant, vous autorisez GeeksforGeek à accéder à certaines informations de votre compte Google, telles que le nom d'utilisateur, la photo de profil, etc.

Historique d'OAuth

Le protocole OAuth 1.0 a été publié sous la forme de RFC 5849, une demande de commentaires informative, en avril 2010.

Le protocole OAuth 2.0 a été publié sous la forme de RFC 6749, et l'utilisation des jetons porteurs OAuth 2.0 a été publiée sous la forme de RFC 6750, en octobre 2012.

Bien qu'il soit basé sur l'expérience de déploiement d'OAuth 1.0, OAuth 2.0 est une réécriture complète d'OAuth 1.0, partageant uniquement les objectifs globaux et l'expérience utilisateur générale. OAuth 2.0 n'est pas rétrocompatible avec OAuth 1.0.

Fonctionnement d'OAuth 2.0

Dans le protocole OAuth, au lieu d'utiliser le nom d'utilisateur et le mot de passe du propriétaire de la ressource pour accéder aux ressources protégées, le client utilise un jeton d'accès. Le client obtient le jeton d'accès d'un serveur d'autorisation après l'approbation du propriétaire de la ressource. Pour que le propriétaire de la ressource accorde l'autorisation au client, il doit d'abord être authentifié sur l'application. Et puisque l'authentification n'a eu lieu qu'entre le propriétaire de la ressource et l'application, le client tiers ne peut pas connaître d'informations privées du propriétaire de la ressource.

Nous pouvons voir que la mise en œuvre du protocole OAuth simplifiera considérablement le processus d'authentification du client tiers. Tout ce qu'il a à faire est d'obtenir l'autorisation de l'utilisateur, de demander le jeton d'accès, de l'utiliser et d'obtenir les informations de l'utilisateur (ressource protégée). Il ne nécessitera pas que les nouveaux utilisateurs enregistrent des comptes ou exposent leurs identifiants, réduisant ainsi la surface d'attaque et augmentant la sécurité du réseau.

Il est important de noter qu'OAuth n'est pas une authentification. Le Auth ici est une autorisation. L'utilisateur ne se connecte pas à l'application. Il autorise simplement l'application tierce à obtenir certaines de ses informations.

Processus d'autorisation d'OAuth

Rôles

OAuth définit quatre rôles :

Client - L'application qui souhaite accéder à vos données (propriétaire de la ressource) et faire des demandes de ressources protégées au nom du propriétaire de la ressource et avec son autorisation.

Propriétaire de la ressource - Un utilisateur qui possède les données dans le serveur de ressources, souhaite utiliser le service du client et possède un compte sur le serveur d'autorisation. Par exemple, je suis le propriétaire de la ressource de mon profil Facebook, et je souhaite utiliser le service de GeeksforGeeks.

Serveur d'autorisation - Le moteur principal d'OAuth. Émet des jetons d'accès au client après avoir authentifié avec succès le propriétaire de la ressource et obtenu l'autorisation.

Serveur de ressources - Le serveur qui stocke les données que le client souhaite, capable d'accepter et de répondre aux demandes de ressources protégées en utilisant des jetons d'accès.

Flux du protocole OAuth

Étape A : L'application tierce demande une autorisation à l'utilisateur

Étape B : L'application tierce reçoit une autorisation, qui est une preuve représentant l'autorisation du propriétaire de la ressource

Étape C : L'application tierce demande un jeton d'accès en utilisant l'autorisation

Étape D : Le serveur d'autorisation authentifie le client et valide l'autorisation, si elle est valide, il émet un jeton d'accès à l'application tierce

Étape E : L'application tierce utilise le jeton d'accès pour demander les ressources protégées au serveur de ressources

Étape F : Le serveur de ressources valide le jeton d'accès et sert la demande si elle est valide

Code d'autorisation et jeton d'accès

Il existe quatre types d'autorisation pour obtenir des jetons d'accès des serveurs d'autorisation. Nous ne parlerons ici que de la méthode Authorization Code, car c'est la méthode la plus sûre et la plus courante.

Étape A : L'application tierce permet à l'utilisateur de choisir une méthode d'autorisation, telle que GitHub, puis redirige l'utilisateur vers le serveur d'autorisation avec des paramètres tels que client_id et redirect_uri

Exemple de demande :

    GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
        &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
    Host: server.example.com

Étape B : L'utilisateur se connecte et autorise

Étape C : Le serveur d'autorisation redirige l'utilisateur vers le backend de l'application tierce selon le redirect_uri, en fournissant le code d'autorisation

Exemple de réponse :

     HTTP/1.1 302 Found
     Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
               &state=xyz

Étape D : L'application tierce utilise le code d'autorisation pour échanger contre le jeton d'accès auprès du serveur d'autorisation

Exemple de demande :

     POST /token HTTP/1.1
     Host: server.example.com
     Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
     Content-Type: application/x-www-form-urlencoded

     grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
     &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

Étape E : Le serveur d'autorisation valide et retourne le jeton d'accès

Exemple de réponse du serveur d'autorisation :

     HTTP/1.1 200 OK
     Content-Type: application/json;charset=UTF-8
     Cache-Control: no-store
     Pragma: no-cache

     {
       "access_token":"2YotnFZFEjr1zCsicMWpAA",
       "token_type":"example",
       "expires_in":3600,
       "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
       "example_parameter":"example_value"
     }

Un exemple concret

Bob souhaite afficher joliment ses commandes Amazon en utilisant un logiciel appelé Rabbit.

Propriétaire de la ressource -> Bob

Client (application tierce) -> Logiciel Rabbit

Serveur d'autorisation -> Serveur d'autorisation d'Amazon

Serveur de ressources -> Bases de données d'Amazon pour stocker les informations de commande

Ressources protégées -> Informations de commande de Bob sur Amazon

Pourquoi le code d'autorisation et le jeton d'accès doivent-ils être obtenus séparément ?

Le code d'autorisation et le jeton d'accès sont obtenus séparément pour garantir des mesures de sécurité.

Dans le protocole OAuth2, le code d'autorisation est un code temporaire que le client échangera contre un jeton d'accès. Le code est obtenu auprès du serveur d'autorisation, où l'utilisateur (propriétaire de la ressource) a la possibilité de voir quelles informations le client demande et d'approuver ou de refuser la demande.

Une fois que l'utilisateur se connecte et autorise avec succès, il est redirigé vers l'application avec un code d'autorisation temporaire dans l'URL.

Ce code d'autorisation est généralement valable pendant dix minutes et une seule fois. La courte période de validité réduit le risque de fuite d'informations utilisateur en cas de vol. En revanche, la période de validité de l'access_token est relativement longue, généralement de 1 à 2 heures. S'il fuit, cela peut représenter un plus grand danger pour la sécurité des données des utilisateurs.

De plus, pour échanger contre un jeton d'accès, le client devra fournir client ID et client secret en plus du code d'autorisation. Le serveur d'autorisation a besoin de ces paramètres pour authentifier le client et vérifier que celui qui demande le jeton d'accès est digne de confiance. Si le code d'autorisation est malheureusement divulgué, mais que le pirate n'a pas le client ID et le client secret, il ne pourra toujours pas obtenir le code d'accès. Même s'il a d'une manière ou d'une autre le client ID et le client secret, il devra encore rivaliser avec le serveur client, car le code d'autorisation n'est valable qu'une seule fois. Ce mécanisme augmente considérablement la difficulté des attaques potentielles. Si nous sautons l'étape d'obtention du code d'autorisation et retournons directement le jeton d'accès, l'attaquant pourrait facilement utiliser le jeton d'accès pour voler des informations utilisateur.

OIDC (OpenID Connect)

Quel est l'objectif d'utiliser OAuth pour l'autorisation ? C'est pour obtenir toutes sortes d'informations sur l'utilisateur. Pourquoi ne pouvons-nous pas standardiser la sortie afin que les applications tierces puissent l'utiliser directement ?

OIDC fait cette standardisation.

Comment OIDC le fait-il ? En bref, il retourne un id_token supplémentaire au format JWT contenant les informations de base de l'utilisateur avec le access token. Les applications tierces peuvent obtenir des informations utilisateur en vérifiant l'algorithme de signature et en vérifiant la signature sur le id_token avec une clé publique.

En outre, OIDC fournit le point de terminaison UserInfo. Les services tiers peuvent utiliser le jeton d'accès pour accéder à ce point de terminaison afin d'obtenir des informations supplémentaires sur l'utilisateur.

Une autre caractéristique d'OIDC est l'authentification unique (SSO) et la déconnexion unique (SLO). SSO améliore l'utilisabilité en permettant à l'utilisateur d'avoir des sessions authentifiées avec différents clients sans avoir à fournir des identifiants à chaque fois. Tant que l'utilisateur se connecte avec succès à une application, il n'a pas besoin de saisir à nouveau le mot de passe lorsqu'il se connecte à d'autres applications.

SLO améliore la sécurité en s'assurant qu'aucune session active n'est laissée à partir d'une session SSO après que l'utilisateur initie une déconnexion unique. Les utilisateurs n'ont besoin de se déconnecter qu'une seule fois et toutes les sessions sont terminées, les empêchant d'être détournées ou mal utilisées.

Il est important de noter qu'OIDC ne standardise pas une méthode d'authentification spécifique, telle que les mots de passe ou la reconnaissance faciale. Au lieu de cela, il spécifie comment déléguer l'authentification à un fournisseur d'authentification centralisé, ce que nous obtenons après l'authentification - id token, comment ce jeton est vérifié - format JWT, et quelles informations utilisateur ce id token contient. Ainsi, les applications tierces n'ont plus besoin de réinventer la roue.

Support d'APISIX pour OAuth/OIDC

Apache APISIX est une passerelle API open-source cloud-native. C'est une passerelle API dynamique, en temps réel et haute performance, et vous pouvez l'utiliser pour gérer le trafic traditionnel nord-sud, ainsi que le trafic est-ouest entre les services. Elle peut également être utilisée comme un contrôleur d'entrée k8s.

Puisque APISIX est une passerelle API qui agit comme un proxy pour plusieurs serveurs d'applications en amont, il est tout à fait naturel de placer l'autorisation centralisée et l'authentification sur la passerelle API.

Le plugin OpenID Connect (OIDC) d'APISIX prend en charge le protocole OpenID Connect. Les utilisateurs peuvent utiliser ce plugin pour connecter APISIX à de nombreux fournisseurs d'identité (IdP), tels que Okta, Keycloak, Ory Hydra, Authing, etc., et le déployer comme une passerelle d'authentification centralisée. OIDC est un sur-ensemble d'OAuth, donc ce plugin prend également en charge OAuth.

Diagramme de déploiement :

Exemple de configuration : Intégrer Keycloak pour l'authentification avec Apache APISIX

Configurer Keycloak

Exemple de code

curl -XPUT 127.0.0.1:9080/apisix/admin/routes/1 -H "X-API-KEY: edd1c9f034335f136f87ad84b625c8f1" -d '{
    "uri":"/anything/*",
    "plugins": {
        "openid-connect": {
            "client_id": "myclient",
            "client_secret": "e91CKZQwhxyDqpkP0YFUJBxiXJ0ikJhq",
            "discovery": "http://127.0.0.1:8080/realms/myrealm/.well-known/openid-configuration",
            "scope": "openid profile",
            "bearer_only": false,
            "realm": "myrealm",
            "redirect_uri": "http://127.0.0.1:9080/anything/callback",
            "logout_path": "/anything/logout"
        }
    },
    "upstream":{
        "type":"roundrobin",
        "nodes":{
            "httpbin.org:80":1
        }
    }
}'

Lorsque vous visitez http://127.0.0.1:9080/anything/test après la création réussie de l'API, vous serez redirigé vers la page de connexion de Keycloak car vous n'êtes pas connecté :

Entrez myuser comme nom d'utilisateur et mypassword comme mot de passe, et vous serez redirigé vers la page suivante.

Visitez http://127.0.0.1:9080/anything/logout pour vous déconnecter :

Résumé

En bref, la norme OAuth est une solution populaire pour les applications et les utilisateurs. Elle offre commodité et sécurité en permettant aux utilisateurs d'utiliser des services sur plusieurs plateformes sans partager leurs identifiants. Apache APISIX est une passerelle API populaire qui prend en charge l'intégration de divers fournisseurs d'identité (Keycloak, Ory Hydra, Okta, Auth0, etc.) pour protéger vos API.

Lisez plus de sessions :

• OIDC dans Apache APISIX
• Utiliser Keycloak avec une passerelle API pour sécuriser les API
• APISIX s'intègre avec Ory Hydra
• Plugin openid-connect d'APISIX