Authentification personnalisée dans Azure Static Web Apps

Azure Static Web Apps fournit une authentification managée qui utilise les inscriptions de fournisseur gérées par Azure. Pour bénéficier d’une plus grande souplesse au niveau de l’inscription, vous pouvez remplacer les valeurs par défaut par une inscription personnalisée.

• L’authentification personnalisée vous permet également de configurer des fournisseurs personnalisés qui prennent en charge OpenID Connect. Cette configuration permet l’inscription de plusieurs fournisseurs externes.

• Dans le cas de l’utilisation d’une inscription personnalisée, tous les fournisseurs préconfigurés sont désactivés.

Remarque

L’authentification personnalisée est uniquement disponible dans le plan Standard d’Azure Static Web Apps.

Configurer un fournisseur d’identité personnalisé

Les fournisseurs d’identité personnalisés sont configurés dans la section auth du fichier config.

Pour éviter de placer des secrets dans le contrôle de code source, la configuration recherche dans les paramètres d’application un nom correspondant dans le fichier config. Vous pouvez également choisir de stocker vos secrets dans Azure Key Vault.

Microsoft Entra ID

Pour créer l’inscription, commencez par créer les paramètres d’application suivants :

Nom du paramètre	Valeur
AZURE_CLIENT_ID	ID d’application (client) pour l’inscription de l’application Microsoft Entra.
`AZURE_CLIENT_SECRET_APP_SETTING_NAME	Nom du paramètre d’application qui contient la clé secrète client pour l’inscription de l’application Microsoft Entra.

Ensuite, utilisez l’exemple suivant pour configurer le fournisseur dans le fichier config.

Les fournisseurs Microsoft Entra sont disponibles dans deux versions différentes. La version 1 définit explicitement le userDetailsClaim, qui permet à la charge utile de retourner des informations utilisateur. Inversement, la version 2 renvoie des informations utilisateur par défaut, et est désignée par v2.0 dans l’URL openIdIssuer.

Microsoft Entra Version 1

{
  "auth": {
    "identityProviders": {
      "azureActiveDirectory": {
        "userDetailsClaim": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name",
        "registration": {
          "openIdIssuer": "https://login.microsoftonline.com/<TENANT_ID>",
          "clientIdSettingName": "AZURE_CLIENT_ID",
          "clientSecretSettingName": "AZURE_CLIENT_SECRET_APP_SETTING_NAME"
        }
      }
    }
  }
}

Veillez à remplacer <TENANT_ID> par votre ID de locataire Microsoft Entra.

Microsoft Entra Version 2

{
  "auth": {
    "identityProviders": {
      "azureActiveDirectory": {
        "registration": {
          "openIdIssuer": "https://login.microsoftonline.com/<TENANT_ID>/v2.0",
          "clientIdSettingName": "AZURE_CLIENT_ID",
          "clientSecretSettingName": "AZURE_CLIENT_SECRET_APP_SETTING_NAME"
        }
      }
    }
  }
}

Veillez à remplacer <TENANT_ID> par votre ID de locataire Microsoft Entra.

Pour plus d’informations sur la configuration de Microsoft Entra ID, consultez la documentation d’authentification/autorisation App Service d’une inscription existante.

Pour configurer les comptes qui peuvent se connecter, consultez Modifier les comptes pris en charge par une application et Restreindre votre application Microsoft Entra à un ensemble d’utilisateurs dans un locataire Microsoft Entra.

Remarque

Tandis que la section de configuration de Microsoft Entra ID est azureActiveDirectory, la plateforme prend l’alias de aad dans l’URL pour la connexion, la déconnexion et la purge des informations utilisateur. Consultez la section authentification et autorisation pour plus d’informations.

Certificat personnalisé

Suivez les étapes suivantes pour ajouter un certificat personnalisé à votre inscription d’application Microsoft Entra ID.

1. Si ce n’est pas déjà le cas, chargez votre certificat dans un coffre de clés Microsoft.

2. Ajoutez une identité managée sur votre application web statique.

   Pour les identités managées attribuées à des utilisateurs, définissez la propriété keyVaultReferenceIdentityde votre objet de site statique sur la resourceId de l’identité managée attribuée à l’utilisateur.

   Ignorez cette étape si votre identité managée est attribuée par le système.

3. Accordez à l’identité managée les stratégies d’accès suivantes :

   • Secrets : Obtenir/répertorier
   • Certificats : Obtenir/répertorier

4. Mettez à jour la section de configuration d’authentification de la section de configuration azureActiveDirectory avec une valeur clientSecretCertificateKeyVaultReference, comme illustré dans l’exemple suivant :

   {
     "auth": {
       "rolesSource": "/api/GetRoles",
       "identityProviders": {
         "azureActiveDirectory": {
           "userDetailsClaim": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
           "registration": {
             "openIdIssuer": "https://login.microsoftonline.com/common/v2.0",
             "clientIdSettingName": "AZURE_CLIENT_ID",
             "clientSecretCertificateKeyVaultReference": "@Microsoft.KeyVault(SecretUri=https://<KEY_VAULT_NAME>.azure.net/certificates/<CERTIFICATE_NAME>/<CERTIFICATE_VERSION_ID>)",
             "clientSecretCertificateThumbprint": "*"
           }
         }
       }
     }
   }
   

   Veillez à remplacer vos valeurs par les espaces réservés entourés de <>.

   Dans l’URI secret, spécifiez le nom du coffre de clés et le nom du certificat. Si vous souhaitez préciser une version, incluez la version du certificat, sinon omettez la version pour permettre au moteur d’exécution de sélectionner la version la plus récente du certificat.

   Pour que la dernière version de l’empreinte du certificat soit toujours utilisée, définissez clientSecretCertificateThumbprint égal à *.

Pomme

Pour créer l’inscription, commencez par créer les paramètres d’application suivants :

Nom du paramètre	Valeur
APPLE_CLIENT_ID	ID client Apple.
APPLE_CLIENT_SECRET_APP_SETTING_NAME	Nom du paramètre d’application qui contient la clé secrète client Apple.

Ensuite, utilisez l’exemple suivant pour configurer le fournisseur dans le fichier config.

{
  "auth": {
    "identityProviders": {
      "apple": {
        "registration": {
          "clientIdSettingName": "APPLE_CLIENT_ID",
          "clientSecretSettingName": "APPLE_CLIENT_SECRET_APP_SETTING_NAME"
        }
      }
    }
  }
}

Pour plus d’informations sur la configuration d’Apple en tant que fournisseur d’authentification, consultez la documentation relative à l’authentification et à l’autorisation d’App Service.

Facebook

Pour créer l’inscription, commencez par créer les paramètres d’application suivants :

Nom du paramètre	Valeur
FACEBOOK_APP_ID	ID d'application Facebook.
FACEBOOK_APP_SECRET_APP_SETTING_NAME	Nom du paramètre d’application qui contient le secret d’application Facebook.

Ensuite, utilisez l’exemple suivant pour configurer le fournisseur dans le fichier config.

{
  "auth": {
    "identityProviders": {
      "facebook": {
        "registration": {
          "appIdSettingName": "FACEBOOK_APP_ID",
          "appSecretSettingName": "FACEBOOK_APP_SECRET_APP_SETTING_NAME"
        }
      }
    }
  }
}

Pour plus d’informations sur la configuration de Facebook en tant que fournisseur d’authentification, consultez la documentation relative à l’authentification et à l’autorisation d’App Service.

GitHub

Pour créer l’inscription, commencez par créer les paramètres d’application suivants :

Nom du paramètre	Valeur
GITHUB_CLIENT_ID	ID client GitHub.
GITHUB_CLIENT_SECRET_APP_SETTING_NAME	Nom du paramètre d’application qui contient la clé secrète client GitHub.

Ensuite, utilisez l’exemple suivant pour configurer le fournisseur dans le fichier config.

{
  "auth": {
    "identityProviders": {
      "github": {
        "registration": {
          "clientIdSettingName": "GITHUB_CLIENT_ID",
          "clientSecretSettingName": "GITHUB_CLIENT_SECRET_APP_SETTING_NAME"
        }
      }
    }
  }
}

Google

Pour créer l’inscription, commencez par créer les paramètres d’application suivants :

Nom du paramètre	Valeur
GOOGLE_CLIENT_ID	ID de client Google.
GOOGLE_CLIENT_SECRET_APP_SETTING_NAME	Nom du paramètre d’application qui contient la clé secrète client Google.

Ensuite, utilisez l’exemple suivant pour configurer le fournisseur dans le fichier config.

{
  "auth": {
    "identityProviders": {
      "google": {
        "registration": {
          "clientIdSettingName": "GOOGLE_CLIENT_ID",
          "clientSecretSettingName": "GOOGLE_CLIENT_SECRET_APP_SETTING_NAME"
        }
      }
    }
  }
}

Pour plus d’informations sur la configuration de Google en tant que fournisseur d’authentification, consultez la documentation relative à l’authentification et à l’autorisation d’App Service.

X

Pour créer l’inscription, commencez par créer les paramètres d’application suivants :

Nom du paramètre	Valeur
X_CONSUMER_KEY	La clé du consommateur X.
X_CONSUMER_SECRET_APP_SETTING_NAME	Le nom du paramètre d’application qui contient le secret du client X.

Ensuite, utilisez l’exemple suivant pour configurer le fournisseur dans le fichier config.

{
  "auth": {
    "identityProviders": {
      "twitter": {
        "registration": {
          "consumerKeySettingName": "X_CONSUMER_KEY",
          "consumerSecretSettingName": "X_CONSUMER_SECRET_APP_SETTING_NAME"
        }
      }
    }
  }
}

Pour plus d’informations sur la configuration de X en tant que fournisseur d’authentification, consultez la documentation relative à l’authentification et l’autorisation d’App Service.

OpenID Connect

Vous pouvez configurer Azure Static Web Apps pour utiliser un fournisseur d’authentification personnalisé conforme à la spécification OpenID Connect (OIDC). Les étapes suivantes sont nécessaires pour utiliser un fournisseur OIDC personnalisé.

• Un ou plusieurs fournisseurs OIDC sont autorisés.
• Chaque fournisseur doit avoir un nom unique dans la configuration.
• Un seul fournisseur peut servir de cible de redirection par défaut.

Inscrire votre application auprès du fournisseur d’identité

Vous devez enregistrer les détails de votre application auprès d’un fournisseur d’identité. Vérifiez auprès du fournisseur les étapes nécessaires à la génération d’un ID client et d’une clé secrète client pour votre application.

Une fois l’application inscrite auprès du fournisseur d’identité, créez les secrets d’application suivants dans les paramètres d’application de l’application web statique :

Nom du paramètre	Valeur
MY_PROVIDER_CLIENT_ID	L’ID client généré par le fournisseur d’authentification pour votre application web statique.
MY_PROVIDER_CLIENT_SECRET_APP_SETTING_NAME	Nom du paramètre d’application qui contient la clé secrète client générée par l’inscription personnalisée du fournisseur d’authentification pour votre application web statique.

Si vous inscrivez d’autres fournisseurs, chacun d’entre eux a besoin d’un ID client associé et d’une clé secrète client stockée dans les paramètres de l’application.

Important

Les secrets d’application sont des informations d’identification de sécurité sensibles. Ne partagez ce secret avec personne, ne le distribuez pas dans une application cliente et ne l’archivez pas dans le contrôle de code source.

Une fois que vous disposez des informations d’identification de l’inscription, procédez comme suit pour créer une inscription personnalisée.

1. Vous avez besoin des métadonnées OpenID Connect pour le fournisseur. Ces informations sont souvent exposées via un document de métadonnées de configuration, qui est l’URL d’émetteur du fournisseur avec le suffixe /.well-known/openid-configuration. Notez cette URL de configuration.

2. Ajoutez une section auth du fichier config avec un bloc de configuration pour les fournisseurs OIDC et la définition de votre fournisseur.

   {
     "auth": {
       "identityProviders": {
         "customOpenIdConnectProviders": {
           "myProvider": {
             "registration": {
               "clientIdSettingName": "MY_PROVIDER_CLIENT_ID",
               "clientCredential": {
                 "clientSecretSettingName": "MY_PROVIDER_CLIENT_SECRET_APP_SETTING_NAME"
               },
               "openIdConnectConfiguration": {
                 "wellKnownOpenIdConfiguration": "https://<PROVIDER_ISSUER_URL>/.well-known/openid-configuration"
               }
             },
             "login": {
               "nameClaimType": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name",
               "scopes": [],
               "loginParameterNames": []
             }
           }
         }
       }
     }
   }
   

• Le nom du fournisseur, myProvider dans cet exemple, est l’identifiant unique utilisé par Azure Static Web Apps.
• Assurez-vous de remplacer <PROVIDER_ISSUER_URL> par le chemin de l’URL de l’émetteur du fournisseur.
• L’objet login vous permet de fournir des valeurs pour : les champs d’application personnalisés, les paramètres de connexion ou les revendications personnalisées.

Rappels d’authentification

Les fournisseurs d’identité ont besoin d’une URL de redirection pour terminer la requête de connexion ou de déconnexion. La plupart des fournisseurs exigent que vous ajoutiez les URL de rappel à une liste d’autorisation. Les points de terminaison suivants sont disponibles comme destinations de redirection.

Type	Modèle d’URL
Connexion	https://<YOUR_SITE>/.auth/login/<PROVIDER_NAME_IN_CONFIG>/callback
Logout	https://<YOUR_SITE>/.auth/logout/<PROVIDER_NAME_IN_CONFIG>/callback

Si vous utilisez Microsoft Entra ID, utilisez aad comme valeur de l’espace réservé <PROVIDER_NAME_IN_CONFIG>.

Remarque

Ces URL sont fournies par Azure Static Web Apps pour recevoir la réponse du fournisseur d’authentification ; vous n’avez pas besoin de créer des pages sur ces itinéraires.

Informations de connexion, de déconnexion et de l’utilisateur

Pour utiliser un fournisseur d’identité personnalisé, utilisez les modèles d’URL suivants.

Action	Modèle
Connexion	/.auth/login/<PROVIDER_NAME_IN_CONFIG>
Logout	/.auth/logout
Détails sur l’utilisateur	/.auth/me
Suppression définitive des détails de l’utilisateur	/.auth/purge/<PROVIDER_NAME_IN_CONFIG>

Si vous utilisez Microsoft Entra ID, utilisez aad comme valeur de l’espace réservé <PROVIDER_NAME_IN_CONFIG>.

Gérer les rôles

Tous les utilisateurs qui accèdent à une application web statique appartiennent à un ou plusieurs rôles. Les utilisateurs peuvent appartenir à deux rôles intégrés :

• anonyme : Tous les utilisateurs appartiennent automatiquement au rôle anonyme.
• authentifié : tous les utilisateurs qui sont connectés appartiennent au rôle authentifié.

Outre les rôles intégrés, vous pouvez attribuer des rôles personnalisés aux utilisateurs et les référencer dans le fichier staticwebapp.config.json.

Invitations

Ajouter un utilisateur à un rôle

Pour ajouter un utilisateur à un rôle, il faut générer des invitations permettant d’associer des utilisateurs à des rôles spécifiques. Les rôles sont définis et gérés dans le fichier staticwebapp.config.json.

Créer une invitation

Les invitations sont spécifiques à chaque fournisseur d’autorisation. Tenez compte des besoins de votre application lorsque vous sélectionnez les fournisseurs à utiliser. Certains fournisseurs exposent l’adresse e-mail de l’utilisateur, tandis que d’autres fournissent uniquement le nom d’utilisateur sur le site.

Fournisseur d’autorisation	Expose
Microsoft Entra ID	de l’adresse de messagerie
GitHub	username
X	username

Suivez les étapes suivantes pour créer une invitation.

1. Accédez à la ressource Static Web Apps sur le portail Azure.
2. Sous Paramètres, sélectionnez Gestion des rôles
3. Sélectionnez Inviter.
4. Sélectionnez un fournisseur d’autorisation dans la liste des options.
5. Ajoutez le nom d’utilisateur ou l’adresse e-mail du destinataire dans la zone Détails sur l’invité.
   • Pour GitHub et X, entrez le nom d’utilisateur. Pour tous les autres, entrez l’adresse e-mail du destinataire.
6. Sélectionnez le domaine de votre site statique dans le menu déroulant Domaine.
   • Le domaine que vous sélectionnez est le domaine qui apparaît dans l’invitation. Si un domaine personnalisé est associé à votre site, choisissez-le.
7. Ajoutez une liste séparée par des virgules de noms de rôles dans la zone Rôle.
8. Entrez le nombre d’heures pendant lesquelles vous souhaitez que l’invitation reste valide.
   • La limite maximale est de 168 heures, soit 7 jours.
9. Sélectionnez Générer.
10. Copiez le lien dans la zone Lien d’invitation.
11. Envoyez par e-mail le lien d’invitation à l’utilisateur auquel vous accordez l’accès.

Quand l’utilisateur sélectionne le lien dans l’invitation, il est invité à se connecter avec son compte correspondant. Une fois que l’utilisateur est connecté, il est associé aux rôles sélectionnés.

Attention

Vérifiez que vos règles d’acheminement ne sont pas en conflit avec les fournisseurs d’authentification sélectionnés. Le blocage d’un fournisseur avec une règle d’acheminement empêche les utilisateurs d’accepter des invitations.

Mettre à jour les attributions de rôles

1. Accédez à la ressource Static Web Apps sur le portail Azure.
2. Sous Paramètres, sélectionnez Gestion des rôles
3. Sélectionnez l’utilisateur dans la liste.
4. Modifiez la liste des rôles dans la zone Rôle.
5. Sélectionnez Mettre à jour.

Supprimer l’utilisateur

1. Accédez à la ressource Static Web Apps sur le portail Azure.
2. Sous Paramètres, sélectionnez Gestion des rôles
3. Recherchez l’utilisateur dans la liste.
4. Activez la case à cocher sur la ligne de l’utilisateur.
5. Sélectionnez Supprimer.

Lorsque vous supprimez un utilisateur, vous devez garder à l’esprit les considérations suivantes :

• La suppression d’un utilisateur invalide ses autorisations.
• La propagation globale peut prendre quelques minutes.
• Si l’utilisateur est de nouveau ajouté à l’application, le userId change.

Fonction (préversion)

Au lieu d’utiliser le système d’invitations intégré, vous pouvez utiliser une fonction serverless pour attribuer programmatiquement des rôles aux utilisateurs quand ils se connectent.

Pour attribuer des rôles personnalisés dans une fonction, vous pouvez définir une fonction d’API qui est automatiquement appelée chaque fois qu’un utilisateur réussit à s’authentifier auprès d’un fournisseur d’identité. La fonction reçoit les informations de l’utilisateur de la part du fournisseur. Elle doit renvoyer une liste des rôles personnalisés qui sont attribués à l’utilisateur.

Voici quelques exemples d’utilisation de cette fonction :

• Interroger une base de données pour déterminer les rôles à attribuer à un utilisateur
• Appeler l’API Microsoft Graph pour déterminer les rôles d’un utilisateur en fonction de son appartenance à un groupe Active Directory
• Déterminer les rôles d’un utilisateur en fonction des revendications renvoyées par le fournisseur d’identité

Remarque

La possibilité d’attribuer des rôles par le biais d’une fonction n’est disponible que lorsque l’authentification personnalisée est configurée.

Lorsque cette fonctionnalité est activée, tous les rôles attribués via le système d’invitations intégré sont ignorés.

Configurer une fonction pour attribuer des rôles

Pour configurer Static Web Apps afin d’utiliser une fonction d’API comme fonction d’attribution de rôle, ajoutez une propriété rolesSource à la section auth du fichier config de votre application. La valeur de la propriété rolesSource est le chemin d’accès à la fonction d’API.

{
  "auth": {
    "rolesSource": "/api/GetRoles",
    "identityProviders": {
      // ...
    }
  }
}

Remarque

Une fois configurée, la fonction d’attribution de rôle n’est plus accessible par des requêtes HTTP externes.

Créer une fonction pour attribuer des rôles

Après avoir défini la propriété rolesSource dans la configuration de votre application, ajoutez une fonction d’API dans votre application web statique à l’emplacement indiqué. Vous pouvez utiliser une application de fonction managée ou apporter votre propre application de fonction.

Chaque fois qu’un utilisateur s’authentifie auprès d’un fournisseur d’identité, la méthode POST appelle la fonction spécifiée. La fonction transmet un objet JSON dans le corps de la demande qui contient les informations du fournisseur sur l’utilisateur. Pour certains fournisseurs d’identité, les informations de l’utilisateur comprennent également un accessToken que la fonction peut utiliser pour effectuer des appels d’API en utilisant l’identité de l’utilisateur.

Consultez l’exemple suivant de charge utile de Microsoft Entra ID :

{
  "identityProvider": "aad",
  "userId": "72137ad3-ae00-42b5-8d54-aacb38576d76",
  "userDetails": "ellen@contoso.com",
  "claims": [
      {
          "typ": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
          "val": "ellen@contoso.com"
      },
      {
          "typ": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname",
          "val": "Contoso"
      },
      {
          "typ": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname",
          "val": "Ellen"
      },
      {
          "typ": "name",
          "val": "Ellen Contoso"
      },
      {
          "typ": "http://schemas.microsoft.com/identity/claims/objectidentifier",
          "val": "7da753ff-1c8e-4b5e-affe-d89e5a57fe2f"
      },
      {
          "typ": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
          "val": "72137ad3-ae00-42b5-8d54-aacb38576d76"
      },
      {
          "typ": "http://schemas.microsoft.com/identity/claims/tenantid",
          "val": "3856f5f5-4bae-464a-9044-b72dc2dcde26"
      },
      {
          "typ": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name",
          "val": "ellen@contoso.com"
      },
      {
          "typ": "ver",
          "val": "1.0"
      }
  ],
  "accessToken": "eyJ0eXAiOiJKV..."
}

La fonction peut utiliser les informations de l’utilisateur pour déterminer les rôles à lui attribuer. Elle doit renvoyer une réponse HTTP 200 avec un corps JSON contenant une liste de noms de rôles personnalisés à attribuer à l’utilisateur.

Par exemple, pour attribuer à l’utilisateur les rôles Reader et Contributor, renvoyez la réponse suivante :

{
  "roles": [
    "Reader",
    "Contributor"
  ]
}

Si vous ne souhaitez pas attribuer d’autres rôles à l’utilisateur, renvoyez un tableau roles vide.

Pour en savoir plus, consultez Tutoriel : Attribuer des rôles personnalisés avec une fonction et Microsoft Graph.

Étapes suivantes

définir des rôles d’utilisateur par programme