Aplikacja klasyczna, która wywołuje internetowe interfejsy API: uzyskiwanie tokenu przy użyciu zintegrowanego uwierzytelniania systemu Windows
Aby zalogować użytkownika domeny na maszynie przyłączonej do domeny lub firmy Microsoft Entra, użyj zintegrowanego uwierzytelniania systemu Windows (IWA).
Ograniczenia
Zintegrowane uwierzytelnianie systemu Windows jest dostępne tylko dla użytkowników federacyjnych+ , czyli użytkowników utworzonych w usłudze Active Directory i wspieranych przez microsoft Entra ID. Użytkownicy utworzeni bezpośrednio w usłudze Microsoft Entra ID bez tworzenia kopii zapasowych usługi Active Directory, znanej jako użytkownicy zarządzani , nie mogą używać tego przepływu uwierzytelniania. To ograniczenie nie ma wpływu na przepływ nazwy użytkownika i hasła.
Usługa IWA nie pomija uwierzytelniania wieloskładnikowego (MFA). Jeśli uwierzytelnianie wieloskładnikowe jest skonfigurowane, uwierzytelnianie wieloskładnikowe może zakończyć się niepowodzeniem, jeśli wymagane jest wyzwanie uwierzytelniania wieloskładnikowego, ponieważ uwierzytelnianie wieloskładnikowe wymaga interakcji z użytkownikiem.
Usługa IWA nie jest interaktywna, ale uwierzytelnianie wieloskładnikowe wymaga interakcyjności użytkownika. Nie kontrolujesz, kiedy dostawca tożsamości żąda uwierzytelniania wieloskładnikowego do wykonania, administrator dzierżawy to robi. Z naszych obserwacji uwierzytelnianie wieloskładnikowe jest wymagane po zalogowaniu się z innego kraju/regionu, gdy połączenie nie jest połączone za pośrednictwem sieci VPN do sieci firmowej, a czasami nawet w przypadku połączenia za pośrednictwem sieci VPN. Nie oczekuj deterministycznego zestawu reguł. Microsoft Entra ID używa sztucznej inteligencji do ciągłego uczenia się, czy uwierzytelnianie wieloskładnikowe jest wymagane. Wróć do monitu użytkownika, takiego jak interakcyjne uwierzytelnianie lub przepływ kodu urządzenia, jeśli awaria interfejsu IWA zakończy się niepowodzeniem.
Urząd przekazany
PublicClientApplicationBuilder
musi być:- Dzierżawa formularza
https://login.microsoftonline.com/{tenant}/
, gdzietenant
jest identyfikatorEM GUID reprezentującym identyfikator dzierżawy lub domeną skojarzona z dzierżawą. - W przypadku wszystkich kont służbowych:
https://login.microsoftonline.com/organizations/
. - Konta osobiste Microsoft nie są obsługiwane. Nie można używać /common lub /consumers dzierżaw.
- Dzierżawa formularza
Ponieważ zintegrowane uwierzytelnianie systemu Windows jest przepływem dyskretnym:
- Użytkownik aplikacji musi wcześniej wyrazić zgodę na korzystanie z aplikacji.
- Lub administrator dzierżawy musi wcześniej wyrazić zgodę na wszystkich użytkowników w dzierżawie w celu korzystania z aplikacji.
- Innymi słowy:
- Jako deweloper wybrano przycisk Udziel w witrynie Azure Portal dla siebie.
- Lub administrator dzierżawy wybrał przycisk Udziel/odwołaj zgody administratora dla {domeny dzierżawy} na karcie Uprawnienia interfejsu API rejestracji dla aplikacji. Aby uzyskać więcej informacji, zobacz Dodawanie uprawnień dostępu do internetowego interfejsu API.
- Możesz też udostępnić użytkownikom sposób wyrażania zgody na aplikację. Aby uzyskać więcej informacji, zobacz Żądanie zgody poszczególnych użytkowników.
- Możesz też udostępnić administratorowi dzierżawy sposób wyrażania zgody na aplikację. Aby uzyskać więcej informacji, zobacz Zgoda administratora.
Ten przepływ jest włączony dla aplikacji klasycznych .NET, .NET i UWP.
Aby uzyskać więcej informacji na temat zgody, zobacz Platforma tożsamości Microsoft uprawnienia i zgoda.
Dowiedz się, jak z niego korzystać
W MSAL.NET użyj:
AcquireTokenByIntegratedWindowsAuth(IEnumerable<string> scopes)
Zwykle potrzebujesz tylko jednego parametru (scopes
). W zależności od sposobu konfigurowania zasad przez administratora systemu Windows aplikacje na maszynie z systemem Windows mogą nie być dozwolone do wyszukania zalogowanego użytkownika. W takim przypadku użyj drugiej metody , .WithUsername()
i przekaż nazwę użytkownika zalogowanego jako format nazwy UPN, na przykład joe@contoso.com
.
Poniższy przykład przedstawia najbardziej aktualny przypadek z wyjaśnieniami rodzaju wyjątków, które można uzyskać i ich środki zaradcze.
static async Task GetATokenForGraph()
{
string authority = "https://login.microsoftonline.com/contoso.com";
string[] scopes = new string[] { "user.read" };
IPublicClientApplication app = PublicClientApplicationBuilder
.Create(clientId)
.WithAuthority(authority)
.Build();
var accounts = await app.GetAccountsAsync();
AuthenticationResult result = null;
if (accounts.Any())
{
result = await app.AcquireTokenSilent(scopes, accounts.FirstOrDefault())
.ExecuteAsync();
}
else
{
try
{
result = await app.AcquireTokenByIntegratedWindowsAuth(scopes)
.ExecuteAsync(CancellationToken.None);
}
catch (MsalUiRequiredException ex)
{
// MsalUiRequiredException: AADSTS65001: The user or administrator has not consented to use the application
// with ID '{appId}' named '{appName}'.Send an interactive authorization request for this user and resource.
// you need to get user consent first. This can be done, if you are not using .NET (which does not have any Web UI)
// by doing (once only) an AcquireToken interactive.
// If you are using .NET or don't want to do an AcquireTokenInteractive, you might want to suggest the user to navigate
// to a URL to consent: https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id={clientId}&response_type=code&scope=user.read
// AADSTS50079: The user is required to use multi-factor authentication.
// There is no mitigation - if MFA is configured for your tenant and AAD decides to enforce it,
// you need to fallback to an interactive flows such as AcquireTokenInteractive or AcquireTokenByDeviceCode
}
catch (MsalServiceException ex)
{
// Kind of errors you could have (in ex.Message)
// MsalServiceException: AADSTS90010: The grant type is not supported over the /common or /consumers endpoints. Please use the /organizations or tenant-specific endpoint.
// you used common.
// Mitigation: as explained in the message from Azure AD, the authority needs to be tenanted or otherwise organizations
// MsalServiceException: AADSTS70002: The request body must contain the following parameter: 'client_secret or client_assertion'.
// Explanation: this can happen if your application was not registered as a public client application in Azure AD
// Mitigation: in the Azure portal, edit the manifest for your application and set the `allowPublicClient` to `true`
}
catch (MsalClientException ex)
{
// Error Code: unknown_user Message: Could not identify logged in user
// Explanation: the library was unable to query the current Windows logged-in user or this user is not AD or AAD
// joined (work-place joined users are not supported).
// Mitigation 1: on UWP, check that the application has the following capabilities: Enterprise Authentication,
// Private Networks (Client and Server), User Account Information
// Mitigation 2: Implement your own logic to fetch the username (e.g. john@contoso.com) and use the
// AcquireTokenByIntegratedWindowsAuth form that takes in the username
// Error Code: integrated_windows_auth_not_supported_managed_user
// Explanation: This method relies on a protocol exposed by Active Directory (AD). If a user was created in Azure
// Active Directory without AD backing ("managed" user), this method will fail. Users created in AD and backed by
// AAD ("federated" users) can benefit from this non-interactive method of authentication.
// Mitigation: Use interactive authentication
}
}
Console.WriteLine(result.Account.Username);
}
Aby uzyskać listę możliwych modyfikatorów na stronie AcquireTokenByIntegratedWindowsAuthentication, zobacz AcquireTokenByIntegratedWindowsAuthParameterBuilder.
Następne kroki
Przejdź do następnego artykułu w tym scenariuszu, wywołaj internetowy interfejs API z aplikacji klasycznej.