Authentification avec OpenID Connect et Apache APISIX

De nombreuses entreprises sont désireuses de fournir leur fournisseur d’identité : Twitter, Facebook, Google, etc. Pour les petites entreprises, ne pas avoir à gérer les identités est un avantage. Cependant, nous voulons éviter d’être enfermés dans un seul fournisseur. Dans cet article, je souhaite montrer comment utiliser OpenID Connect en utilisant Google ci-dessous, puis passer à Azure.

Connexion OpenID

L’idée d’un autorisation La norme ouverte a commencé avec OAuth vers 2006. En raison d’un problème de sécurité, OAuth 2.0 a remplacé la version initiale. OAuth 2.0 est devenu un IETF RFC en 2012:

Le cadre d’autorisation OAuth 2.0 permet à un tiers
application pour obtenir un accès limité à un service HTTP, soit sur
au nom d’un propriétaire de ressource en orchestrant une interaction d’approbation
entre le propriétaire de la ressource et le service HTTP, ou en autorisant le
application tierce pour obtenir l’accès en son propre nom

– RFC 7469, le cadre d’autorisation OAuth 2.0

OAuth se concentre principalement sur autorisation; le authentification La partie est assez légère : elle contient une section sur l’authentification par mot de passe client et une autre sur les autres méthodes d’authentification.

Le serveur d’autorisation PEUT prendre en charge toute authentification HTTP appropriée
système correspondant à ses exigences de sécurité. Lors de l’utilisation d’autres
méthodes d’authentification, le serveur d’autorisation DOIT définir un
mappage entre l’identifiant du client (dossier d’enregistrement) et
schéma d’authentification.

– 2.3.2. Autres méthodes d’authentification

OpenID Connect utilise OAuth 2.0 et ajoute le authentification partie:

OpenID Connect 1.0 est une simple couche d’identité au-dessus du protocole OAuth 2.0. Il permet aux clients de vérifier l’identité de l’utilisateur final sur la base de l’authentification effectuée par un serveur d’autorisation, ainsi que d’obtenir des informations de profil de base sur l’utilisateur final d’une manière interopérable et de type REST.

OpenID Connect permet aux clients de tous types, y compris les clients Web, mobiles et JavaScript, de demander et de recevoir des informations sur les sessions authentifiées et les utilisateurs finaux. La suite de spécifications est extensible, permettant aux participants d’utiliser des fonctionnalités facultatives telles que le cryptage des données d’identité, la découverte des fournisseurs OpenID et la déconnexion, lorsque cela a du sens pour eux.

– « Qu’est-ce qu’OpenID Connect? »

Voici quelques fournisseurs d’identité compatibles avec OpenID Connect :

• GitHub
• Google
• Microsoft
• Pomme
• Facebook
• Twitter
• Spotify

Dans ce qui suit, nous allons commencer par Google et passer à Azure pour valider notre configuration.

Configuration d’OpenID Connect avec Apache APISIX

Imaginons que nous ayons une application Web derrière Apache APISIX que nous souhaitons sécuriser avec OpenID Connect. Voici le fichier Docker Compose correspondant :

version: "3"

services:
  apisix:
    image: apache/apisix:3.1.0-debian                              #1
    ports:
      - "9080:9080"
    volumes:
      - ./apisix/config.yml:/usr/local/apisix/conf/config.yaml:ro  #2
      - ./apisix/apisix.yml:/usr/local/apisix/conf/apisix.yaml:ro  #3
    env_file:
      - .env
  httpbin:
    image: kennethreitz/httpbin                                    #4

1. Passerelle d’API Apache APISIX
2. Configuration APISIX – utilisé pour le configurer statiquement dans la ligne suivante
3. Configurez la route unique.
4. Webapp à protéger – n’importe lequel fera l’affaire

Apache APISIX propose une architecture basée sur des plugins. L’un de ces plugins est le plugin openid-connect, qui permet d’utiliser OpenID Connect.

Configurons-le :

routes:
  - uri: /*                                                                    #1
    upstream:
      nodes:
        "httpbin:80": 1                                                        #1
    plugins:
      openid-connect:
        client_id: ${{OIDC_CLIENTID}}                                          #2
        client_secret: ${{OIDC_SECRET}}                                        #2
        discovery: https://${{OIDC_ISSUER}}/.well-known/openid-configuration   #2-3
        redirect_uri: http://localhost:9080/callback                           #4
        scope: openid                                                          #5
        session:
          secret: ${{SESSION_SECRET}}                                          #6
#END

1. Route fourre-tout vers l’application Web sous-jacente
2. Paramètres de configuration du plugin – Les valeurs dépendent du fournisseur exact (voir ci-dessous).
3. OpenID Connect peut utiliser un point de terminaison Discovery pour obtenir tous les points de terminaison OAuth nécessaires. Voir la spécification OpenID Connect Discovery 1.0 pour plus d’informations
4. Où rediriger lorsque l’authentification est réussie – Elle ne doit entrer en conflit avec aucune des routes explicitement définies. Le plugin y crée une route dédiée pour opérer sa magie.
5. Portée par défaut
6. Clé pour chiffrer les données de session – Mettez ce que vous voulez.

Configuration de Google pour OIDC

Comme tous les fournisseurs de cloud, Google propose une solution complète de gestion des identités, ce qui peut être décourageant pour les nouveaux arrivants. Dans cette section, je ne détaillerai que les étapes nécessaires à sa configuration pour OIDC.

• Sur Cloud Console, créez un projet dédié (ou utilisez-en un existant).
• Si vous ne l’avez pas déjà fait, personnalisez l’écran de consentement OAuth.
• Dans le contexte du projet, naviguez API et services/Identifiants.

• Sélectionner Identifiant client OAuth dans le menu déroulant.

• Remplissez les champs :
  • Type d’application : application Web
  • Nom: Tout ce que vous voulez
  • URI de redirection autorisés : /callbackpar exemple., http://localhost:9080/callback

URL doit être l’URL de l’application Web. De même, /callback doit correspondre à la openid-connect configuration du plugin ci-dessus. Notez que Google n’autorise pas les URL relatives, donc si vous avez besoin de réutiliser l’application dans différents environnements, vous devez ajouter l’URL de chaque environnement. Clique le Créer bouton.

• Dans la configuration Docker Compose ci-dessus, utilisez l’ID client et le secret client comme OIDC_CLIENTID et OIDC_SECRET. Je les ai écrits comme variables d’environnement dans un .env déposer.
• La dernière variable manquante est OIDC_ISSUER: c’est accounts.google.com. Si vous accédez à cette page, vous verrez toutes les données requises par OAuth 2.0 (et plus).

À ce stade, nous pouvons commencer notre configuration avec docker compose up. Lorsque nous naviguons vers http://localhost:9080/, le navigateur nous redirige vers la page d’authentification Google. Comme je suis déjà authentifié, je peux choisir mon identifiant – et j’en ai besoin d’un lié à l’organisation du projet que j’ai créé ci-dessus.