Partager via


Courtier d'authentification web

Cet article explique comment connecter votre application de plateforme Windows universelle (UWP) à un fournisseur d’identité en ligne qui utilise des protocoles d’authentification tels qu’OpenID ou OAuth. La méthode AuthenticateAsync envoie une demande au fournisseur d’identité en ligne et récupère un jeton d’accès qui décrit les ressources du fournisseur auxquels l’application a accès.

Remarque

Pour obtenir un exemple de code complet et opérationnel, clonez le dépôt WebAuthenticationBroker sur GitHub.

 

Inscrire votre application auprès de votre fournisseur en ligne

Vous devez inscrire votre application auprès du fournisseur d’identité en ligne auquel vous souhaitez vous connecter. Vous pouvez apprendre comment inscrire votre application auprès du fournisseur d’identité. Après l’inscription, le fournisseur en ligne vous donne généralement un ID ou une clé secrète pour votre application.

Générer l’URI de la demande d’authentification

L’URI de requête se compose de l’adresse où vous envoyez la demande d’authentification à votre fournisseur en ligne ajouté avec d’autres informations requises, telles qu’un ID d’application ou un secret, un URI de redirection où l’utilisateur est envoyé après l’authentification et le type de réponse attendu. Vous pouvez découvrir à partir de votre fournisseur quels paramètres sont requis.

L’URI de la requête est envoyé en tant que paramètre requestUri de la méthode AuthenticateAsync. Il doit s’agir d’une adresse sécurisée (elle doit commencer par https://)

L’exemple suivant montre comment générer l’URI de requête.

string startURL = "https://<providerendpoint>?client_id=<clientid>&scope=<scopes>&response_type=token";
string endURL = "http://<appendpoint>";

System.Uri startURI = new System.Uri(startURL);
System.Uri endURI = new System.Uri(endURL);

Se connecter au fournisseur en ligne

Vous appelez la méthode AuthenticateAsync pour vous connecter au fournisseur d’identité en ligne et obtenir un jeton d’accès. La méthode prend l’URI construit à l’étape précédente comme paramètre requestUri et l'URI vers lequel vous souhaitez que l’utilisateur soit redirigé comme paramètre callbackUri.

string result;

try
{
    var webAuthenticationResult = 
        await Windows.Security.Authentication.Web.WebAuthenticationBroker.AuthenticateAsync( 
        Windows.Security.Authentication.Web.WebAuthenticationOptions.None, 
        startURI, 
        endURI);

    switch (webAuthenticationResult.ResponseStatus)
    {
        case Windows.Security.Authentication.Web.WebAuthenticationStatus.Success:
            // Successful authentication. 
            result = webAuthenticationResult.ResponseData.ToString(); 
            break;
        case Windows.Security.Authentication.Web.WebAuthenticationStatus.ErrorHttp:
            // HTTP error. 
            result = webAuthenticationResult.ResponseErrorDetail.ToString(); 
            break;
        default:
            // Other error.
            result = webAuthenticationResult.ResponseData.ToString(); 
            break;
    } 
}
catch (Exception ex)
{
    // Authentication failed. Handle parameter, SSL/TLS, and Network Unavailable errors here. 
    result = ex.Message;
}

Avertissement

Outre AuthenticateAsync, l’espace de noms Windows.Security.Authentication.Web contient une méthode AuthenticateAndContinue. N’appelez pas cette méthode. Il est conçu pour les applications ciblant Windows Phone 8.1 uniquement et est déconseillé à partir de Windows 10.

Connexion avec l’authentification unique (SSO).

Par défaut, le répartiteur d’authentification web n’autorise pas la persistance des cookies. En raison de cela, même si l’utilisateur de l’application indique qu’il souhaite rester connecté (par exemple, en sélectionnant une case à cocher dans la boîte de dialogue de connexion du fournisseur), il devra se connecter chaque fois qu’il souhaite accéder aux ressources de ce fournisseur. Pour vous connecter avec SSO (Single Sign-On), votre fournisseur d’identité en ligne doit avoir activé SSO pour le courtier d'authentification Web, et votre application doit appeler la surcharge de AuthenticateAsync qui ne prend pas de paramètre callbackUri. Cela permet aux cookies persistants d’être stockés par le répartiteur d’authentification web afin que les appels d’authentification futurs par la même application ne nécessitent pas de connexion répétée par l’utilisateur (l’utilisateur est effectivement « connecté » jusqu’à l’expiration du jeton d’accès).

Pour prendre en charge l’authentification unique, le fournisseur en ligne doit vous permettre d’inscrire un URI de redirection dans le formulaire ms-app://<appSID>, où <appSID> est le SID de votre application. Vous pouvez trouver le SID de votre application à partir de la page développeur de l’application pour votre application ou en appelant la méthode GetCurrentApplicationCallbackUri.

string result;

try
{
    var webAuthenticationResult = 
        await Windows.Security.Authentication.Web.WebAuthenticationBroker.AuthenticateAsync( 
        Windows.Security.Authentication.Web.WebAuthenticationOptions.None, 
        startURI);

    switch (webAuthenticationResult.ResponseStatus)
    {
        case Windows.Security.Authentication.Web.WebAuthenticationStatus.Success:
            // Successful authentication. 
            result = webAuthenticationResult.ResponseData.ToString(); 
            break;
        case Windows.Security.Authentication.Web.WebAuthenticationStatus.ErrorHttp:
            // HTTP error. 
            result = webAuthenticationResult.ResponseErrorDetail.ToString(); 
            break;
        default:
            // Other error.
            result = webAuthenticationResult.ResponseData.ToString(); 
            break;
    } 
}
catch (Exception ex)
{
    // Authentication failed. Handle parameter, SSL/TLS, and Network Unavailable errors here. 
    result = ex.Message;
}

Débogage

Il existe plusieurs façons de résoudre les problèmes des API du répartiteur d’authentification web, notamment l’examen des journaux opérationnels et l’examen des demandes et réponses web à l’aide de Fiddler.

Journaux opérationnels

Souvent, vous pouvez déterminer ce qui ne fonctionne pas à l’aide des journaux opérationnels. Il existe un canal de journal des événements dédié Microsoft-Windows-WebAuth\Operational qui permet aux développeurs de sites web de comprendre comment leurs pages web sont traitées par le répartiteur d’authentification web. Pour l’activer, lancez eventvwr.exe et activez le journal opérationnel sous application et services\Microsoft\Windows\WebAuth. En outre, le répartiteur d’authentification web ajoute une chaîne unique à la chaîne de l’agent utilisateur pour s’identifier sur le serveur web. La chaîne est « MSAuthHost/1.0 ». Notez que le numéro de version peut changer à l’avenir. Vous ne devez donc pas dépendre de ce numéro de version dans votre code. Voici un exemple de chaîne d’agent utilisateur complète, suivi de l'intégralité des étapes de débogage.

User-Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; Win64; x64; Trident/6.0; MSAuthHost/1.0)

  1. Activez les journaux opérationnels.
  2. Exécutez l’application sociale Contoso. visionneuse d’événements affichant les journaux opérationnels WebAuth
  3. Les entrées de journaux générées peuvent être utilisées pour comprendre plus en détail le comportement du répartiteur d’authentification web. Dans ce cas, il peut s’agir des éléments suivants :
    • Démarrage de la navigation : enregistre quand AuthHost est démarré et contient des informations sur les URL de début et de fin.
    • illustre les détails du démarrage de navigation
    • Navigation terminée : enregistre la fin du chargement d’une page web.
    • Balise méta : enregistre lorsqu'une balise méta est rencontrée, y compris les détails.
    • Fin de la navigation : la navigation s’est terminée par l’utilisateur.
    • Erreur de navigation : AuthHost rencontre une erreur de navigation sur une URL, y compris HttpStatusCode.
    • Fin de la navigation : l’URL de fin est rencontrée.

Violoniste

Le débogueur web Fiddler peut être utilisé avec des applications. Pour plus d’informations, consultez la documentation Fiddler

  1. Étant donné que AuthHost s’exécute dans son propre conteneur d’applications, pour lui donner la fonctionnalité de réseau privé, vous devez définir une clé de Registre : Éditeur de Registre Windows Version 5.00

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Options d’exécution de fichiers image\authhost.exe\EnablePrivateNetwork = 00000001

    Si vous n’avez pas cette clé de Registre, vous pouvez la créer dans une invite de commandes avec des privilèges d’administrateur.

    REG ADD "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\authhost.exe" /v EnablePrivateNetwork /t REG_DWORD /d 1 /f
    
  2. Ajoutez une règle pour AuthHost, car il s’agit de ce qui génère le trafic sortant.

    CheckNetIsolation.exe LoopbackExempt -a -n=microsoft.windows.authhost.a.p_8wekyb3d8bbwe
    CheckNetIsolation.exe LoopbackExempt -a -n=microsoft.windows.authhost.sso.p_8wekyb3d8bbwe
    CheckNetIsolation.exe LoopbackExempt -a -n=microsoft.windows.authhost.sso.c_8wekyb3d8bbwe
    D:\Windows\System32>CheckNetIsolation.exe LoopbackExempt -s
    List Loopback Exempted AppContainers
    [1] -----------------------------------------------------------------
        Name: microsoft.windows.authhost.sso.c_8wekyb3d8bbwe
        SID:  S-1-15-2-1973105767-3975693666-32999980-3747492175-1074076486-3102532000-500629349
    [2] -----------------------------------------------------------------
        Name: microsoft.windows.authhost.sso.p_8wekyb3d8bbwe
        SID:  S-1-15-2-166260-4150837609-3669066492-3071230600-3743290616-3683681078-2492089544
    [3] -----------------------------------------------------------------
        Name: microsoft.windows.authhost.a.p_8wekyb3d8bbwe
        SID:  S-1-15-2-3506084497-1208594716-3384433646-2514033508-1838198150-1980605558-3480344935
    
  3. Ajoutez une règle de pare-feu pour le trafic entrant vers Fiddler.