Configure Azure Active Directory for UserName-Password Login

Attention: the following configuration is recommended only for testing or very trusted applications, since username and password could be intercepted (since they are entered directly).

By default, Active Directory Applications (App Registrations) are configured so that username and password cannot be entered directly. Instead, a browser window from Microsoft opens with a corresponding login.

Applications thus only receive a token and never the credentials in plain text. This is an intentional behavior and positive for the security of user data.

Automated Logins

The interactive behavior is very positive for the operation of an application. Scenarios like automated logins can definitely be made more difficult this way.

In some scenarios, however, this can also be a hindrance, for example in end-to-end tests that require a login session: many systems only support the direct entry of login data and no interactive implementations.

Enable Public Client Flows

The so-called public client flows are all flows where a direct input of the password becomes necessary or possible.

This includes, for example, the Resource Owner Password Credential Flow or the Device Code Flow. Both flows have legitimate use cases, but they offer less security because the application receives and has to handle the credentials directly.

Microsoft writes about this in its documentation:

Microsoft recommends you do not use the ROPC flow. In most scenarios, more secure alternatives are available and recommended. This flow requires a very high degree of trust in the application, and carries risks which are not present in other flows. You should only use this flow when other more secure flows can't be used.

In the case of end to end testing, however, we deliberately want or need this flow, as we want to be able to log in automatically to test our token-based application in the context of a user. For enabling, the “Allow Public Client Flows” switch in the App Registration (Authentication tab at the bottom) must be set to Yes.

Login with Postman

With Postman, we can now test whether our basically automated login via a tool works.

To do this, we create a POST request with the following settings:

URI for Tenant Apps:https://login.microsoftonline.com/{your tenant id goes here}/oauth2/v2.0/token

URI for Multi Tenant Apps:https://login.microsoftonline.com/organizations/oauth2/v2.0/token

Now, you can run those request and you get the token in your response body. This means the configuration works and you can use this Azure App registration for your E2E tests.

But take care: please use this flow only for testing purposes or if you know this is really a very trusted app!

Autor

Benjamin Abt

Ben is a passionate developer and software architect and especially focused on .NET, cloud and IoT. In his professional he works on high-scalable platforms for IoT and Industry 4.0 focused on the next generation of connected industry based on Azure and .NET. He runs the largest german-speaking C# forum myCSharp.de, is the founder of the Azure UserGroup Stuttgart, a co-organizer of the AzureSaturday, runs his blog, participates in open source projects, speaks at various conferences and user groups and also has a bit free time. He is a Microsoft MVP since 2015 for .NET and Azure.

Originally published at https://schwabencode.com on August 24, 2022.