I'm developing an app that will require users to authenticate via their Azure AD account. Customer would like a branded, custom UI, including the login screen. The current library for Azure AD authentication is MSAL.js. Using this library, the recommended flow is that users are redirected to the Microsoft login page (I guess just like they would be to Facebook or Google authentication services) and must enter their password in there if they're not already logged.

According to this, it is possible but not secure or recommended to ask the user for a password in a custom login screen, what I can understand. But why exactly is it safer to ask the user to enter the password in Microsoft sign in portal (or Google, FB, etc.) instead of directly in the app, assuming the app would not store it and would encrypt communications to acquire the token?

  • 1
    the fewer groups that have your password, the better.
    – dandavis
    Jan 21, 2020 at 18:42
  • Because how does the user know the app isn't storing it? Jan 22, 2020 at 12:10
  • @user253751 He does not, but the question is more why being redirected is 1. safer and 2. better for the user. How can (non technical) users be sure that it is ok to enter their password in the page they been redirected to? Jan 22, 2020 at 17:11
  • @supafly they could look at the address bar, for one thing. Because they were told: don't enter your bank password except on yourbank.com. Jan 22, 2020 at 17:14

4 Answers 4


Is it really safer? Not really. In fact if your app was perfect or at least as thoroughly tested and reviewed than browsers are for the login script part, it would just be as safe on a technical point of view. I assume that your app is correctly written, but what about the tests and reviews point?

Because the most important point here is attack surface. Users have to give their passwords through the browser, so attacks against the browser are a possible vector for capturing passwords. But for any other app that would ask for the password, another possibility of attack.

Another point is user education. Security specialist try hard to educate users that a password is highly sensitive data that should only given to well known and securely identified services. The browser is a well known vector. Whether your app can be depends on its usage: the more often it is used by a user, the best candidate.

So you are left with the good old cost/benefit ratio. What are the additional features or cooler UI elements for having the app manage the password? Do they balance the surface attack increase, and the user stress to give the password in another screen? If the answer is yes, just proceed. Else refrain.

  • I understand these two points, but I think most users are not able to tell the difference between a real and a fake Microsoft login page such as MS login, and hence would enter their usr/pwd in a fake page. Also, not sure being redirected inspires confidence, even if it is indeed a more secure way to authenticate. A lot of people has no idea of what a redirection is. Jan 22, 2020 at 17:08

According to this, it is possible but not secure or recommended to ask the user for a password in a custom login screen, what I can understand.

The main reason for that being frowned upon is because you don't want users to get in the habit of typing in their passwords anywhere other than their respective websites.A malicious website could ask for your google password and the habitual user will give it to them

assuming the app would not store it and would encrypt communications to acquire the token?

Sure,your app might not but there is no way to prove it that you are not storing their passwords,at the end of the day you would want your users to put password at their original website.The specification is a way to curb phishing sites that will ask users for their google passwords and when the users gets into the habit it will make internet security weaker


First, it gives you and extra functionality... For example if you use fb login you can retrieve it profile picture for example... Second, you rely on the service security methods which they work on every day and spend large amounts of money in... Third, makes your app more user friendly... The cons are that of this services are hacked and leak the information of many users... Your app is also compromised. If you use your custom login you could make ot better or worse... It will depend on your security abilities


This is a Password Anti-Pattern and used to be fairly prevalent.

For example, LinkedIn asks for your Twitter password so that your tweets can be posted to LinkedIn.

It’s less common these days as it goes against password best practices. We want to discourage people from sharing their credentials to just any application ( as this is how you get phished)

From the user’s perspective of your app they may be worried about:

  • There is no easy way to revoke access from a 3rd party app apart from changing your password.

  • You have to worry if the 3rd party is securing your credentials.

  • Is that access scoped to specific activities or do your credentials give the 3rd party full access to your account

This problem is one of the reasons OAuth was invented and tries to solve. It’s safer for the user as their credentials are not shared with the 3rd party app that they may or may not trust with those credentials. It’s also good for the 3rd party app because it relieves them of the burden of securing their users credentials.

It’s good and safe for everyone.

  • Thank you for these very good points. I should have mentioned that we're developing an Angular private app for an enterprise. It is assumed trusted. Jan 22, 2020 at 17:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .