In this video, explore the various types of authentication, including legacy methods, that can be used to securely access Azure.
- [Instructor] In this lesson, we are going to examine various authentication methods that are available in Azure, starting with Azure Active Directory because this is the backbone of Azure and other Microsoft services. Azure Active Directory can authenticate our on-premises users, our users in the cloud, and our users' devices and allow communication between all of them. Azure Active Directory supports the following authentication protocols: SAML, WS-Federation, and Open Authorization or OAuth, and we'll be talking about OAuth in depth in an upcoming lesson. In order to authenticate our on-premises users, we need to use Azure Active Directory Connect. In addition to authenticating our users, it also provides synchronization between our users and groups. It'll also provide some health monitoring. When using Azure Active Directory Connect with our on-premises environment, we have a couple choices for authentication, the first one being cloud authentication. Here, we can authenticate our on-premises users using password hash synchronization, PHS, or pass-through authentication, PTA. We can also use AD FS or federated authentication, and all of these provide single sign-on for domain-joined devices that are on the corporate network. For more information on Azure Active Directory and Azure Active Directory Connect, there are already several courses in the library that you can reference. Azure also supports certificate-based authentication, which means our app can be authenticated using Azure Active Directory and a client certificate. There are still two legacy authentication methods that can be used, the first being forms-based authentication. The downfall with this method is it sends users' passwords in cleartext. We never want to do that. It is subject to cross-site request forgeries, and it does require a browser client, but all that being said, legacy app authentication that used SQL Server can easily be migrated to Azure SQL Database with only a change in the connection string. If you're using form-based authentication, I would recommend that you upgrade it using this method. Let's review a forms-based authentication workflow. A user requests access to the resource. If the user's not authenticated, the server will return an HTTP 302 Found, and it will include a login URL. The user will now enter their credentials, and the form will be submitted back to the server. Once again, the server will return an HTTP 302 Found with the login URI and authentication code. The user once again requests access to the resource, but this time, the authentication cookie is included, and the request is granted. The other legacy authentication model is the Windows-Integrated Authentication, or you may hear this referred to as Windows-based authentication. It does require Kerberos or NTLM. Therefore, we only use it with on-premises authentication, and the systems must be domain-joined in order to use this, and Windows-based authentication does not support bring your own devices. Azure also supports ASP.NET claims-based authentication, which handles basic authentication and determines the access to specific resources. ASP.NET Identity can easily modify authentication providers from on-premises to Azure, and this is done by providing the user's identity as a set of claims, which provide rich information about the user. Let's quickly review the claims authentication workflow. We have our application. Our user needs access to an application. That user can then authenticate with their identity providers, those being Facebook, LinkedIn, Google, Twitter, or Azure Active Directory. Once a user has authenticated with our identity provider, they then have access to the application, and our last authentication method that we're going to cover here is the app service authentication and authorization. When we configure an app within Azure, we can require that Azure apps authenticate using authentication providers. This authentication runs outside of the application. No SDKs or changes to the application code are required, and the tokens are saved in a token store for retrieval when needed. That is a high-level overview of various authentication methods within Azure. For more information on any of these methods, please refer to the library for full courses.