Integrated Windows Authentication
by Mike Wasson
Integrated Windows authentication enables users to log in with their Windows credentials, using Kerberos or NTLM. The client sends credentials in the Authorization header. Windows authentication is best suited for an intranet environment. For more information, see Windows Authentication.
| Advantages | Disadvantages |
|---|---|
| Built into IIS. | Not recommended for Internet applications. |
| Does not send the user credentials in the request. | Requires Kerberos or NTLM support in the client. |
| If the client computer belongs to the domain (for example, intranet application), the user does not need to enter credentials. | Client must be in the Active Directory domain. |
Note
If your application is hosted on Azure and you have an on-premise Active Directory domain, consider federating your on-premise AD with Azure Active Directory. That way, users can log in with their on-premise credentials, but the authentication is performed by Azure AD. For more information, see Azure Authentication.
To create an application that uses Integrated Windows authentication, select the "Intranet Application" template in the MVC 4 project wizard. This project template puts the following setting in the Web.config file:
<system.web>
<authentication mode="Windows" />
</system.web>
On the client side, Integrated Windows authentication works with any browser that supports the Negotiate authentication scheme, which includes most major browsers. For .NET client applications, the HttpClient class supports Windows authentication:
HttpClientHandler handler = new HttpClientHandler()
{
UseDefaultCredentials = true
};
HttpClient client = new HttpClient(handler);
Windows authentication is vulnerable to cross-site request forgery (CSRF) attacks. See Preventing Cross-Site Request Forgery (CSRF) Attacks.