• Dana Epp

Using Azure AD for password-based single sign-on (SSO)

Updated: Nov 30, 2018

If you have followed my career at all, you know that in a previous life I built an Identity Provider (IdP) called AuthAnvil that delivered single sign-on (SSO) experience for both federated single sign-on (think WSFED, SAML etc) as well as password-passed SSO. I sold that to Kaseya many years ago. Since that time many companies have popped up doing the same thing like OKTA, OneLogin and even DuoSecurity.

In my latest startup we are heavily invested in the Microsoft Cloud, and I was seriously considering going back to Kaseya to become a customer of my own stuff. But Microsoft has made so many strides as of late, that they offer as good an experience built right into Azure AD. It's nowhere as easy to setup as AuthAnvil ever was, but in the same light, having something baked into the directory service I am already using is compelling.

A fellow Microsoft MVP did a pretty good job of documenting how to setup Azure AD to support 3rd party password-based SSO. In the article, he shows how you can have either administrator or user managed credentials to setup the SSO app. He goes on to showcase how the SSO extension works and how you can login. It is simple enough instructions, and easy to follow. I highly recommend you check it out.

One thing that has bothered me for years though is how SSO vendors and integrators of similar solutions all say this is safe so the user never knows the password. Even this article refers to that. But its a fallacy. As these extensions always inject a credential into the browser window, you cannot consider this credential 'safe' and 'unseen'. Browser based tools like the developer console in Chrome and Fiddler can easily intercept that action and reveal the plain text password. That is one of the values of AuthAnvil, as it has automated password rotation capabilities so a credential revealed in a password-based SSO event could change the password to a new value after it was used directly from the server through a trust chain.

Use SSO. When possible though, use enterprise-class protocols like WSFED and SAML where passwords never need to be shared in the transaction. Or if you use password-based SSO, make sure the aging of passwords is very short. And make sure they are unique between apps, accounts and users. Sharing password SSO is like sharing a toothbrush.... it's just gross.