This is how I login to SSO today at work: Login username is cached in browser. Password is auto-filled-in by my password manager, which is in turn unlocked for a period of time when I am logged into my desktop. I hit "Log In" button. Backend does magic. An app pops up on my phone. I supply my fingerprint. Authentication is approved, and my browser is now logged in.
Same pattern works for logging into AWS from the console. My password manager keeps the username and password. Every time my AWS temporary session token expires, AWS CLI asks saml2aws for a new session token. Saml2aws gets user/password from the password manager, logs in. If session has expired, I get a pop-up on my phone asking me to log in. I supply fingerprint. Authentication is approved, and saml2aws creates a new session, passes it to AWS CLI, and I'm off to the races.
I can control exactly how often I have to enter in a password (to unlock my password manager), and the site administrator determines how long my sessions last. Is it super duper secure? No. But is it better than me typing my password, hitting submit, getting a text message, and typing a code in? Absolutely.
The same pattern can totally work across multiple sites. The standards just need to be changed to allow it to happen. This isn't a technical problem, it's a political one.
The problem is it's much more complex to manage N users in N applications, having a central location to onboard and offboard your users is a huge boon to IT departments. The convenience isn't for you as the user.
As an enterprise cloud software business, I will not allow my systems to handle user-chosen long-lived credentials like the passwords you describe. Sorry, it's too much of liability. Got any other ideas? (sincerely curious)
At some point, your user also has right to make their own policies. Imagine your banker requiring you to take a drug test before they let you do any action, would that be fine by you?
If you were talking about your employees, of course, it's less of an issues, but you are still open to them misusing other solutions: in the end, invasive security policies in a business where people can also use service accounts is a recipe to have people build backdoors in their own security. Good security is only as secure as it is convenient for users.
When I was working in banking, people had physical card readers that would identify them. Of course, some people still forgot them sometimes, but it was also necessary to get out of the desks.
(I made some edits to the previous post, as I figured out you may have talked about people working with you rather than clients)
> I have no issues getting my enterprise customers to configure SSO, so there's no practical reason for me to support password login.
I'm not really sure what you mean when you say SSO. We use Google workspace at work, and use the sso in several of our products. Still, since workspace admin prompts us to relog every damn time, some colleagues use the service account to perform workspace actions. That's a hole of course, as the service account is not supposed to be used for user actions, but it's also more convenient.
Another example, of which I'm guilty, was my previous work's VPN 2FA policy, which my team conveniently skipped with a script doing the oauth call. Of course, not everyone did the script properly (because prompting for your password takes a couple more lines), and so some of us may have had their credentials in the bash file.
This kind of shortcuts is hard to avoid for technical users, and so the golden rule for security in my opinion is that it should be easier to do the right thing. Unfortunately, each person has a different definition of friction, so it's not an easy topic.
> What do you mean by invasive security practices?
It's obviously a personal criterion. To me, invasive starts when people want to get in my phone. It's not really arbitrary, since my phone is a piece of garbage that has no security, but it's a personal thing since others may prefer to have a phone solution.
We certainly agree on the importance of making it easy and convenient for the users to behave well. The traditional example here is onerous password requirements that lead to post-it notes.
> Still, since workspace admin prompts us to relog every damn time, some colleagues use the service account to perform workspace actions. That's a hole of course, as the service account is not supposed to be used for user actions, but it's also more convenient.
This is a great point that I hadn't considered. Thank you!
Sounds ripe for some additional automation involving a synthetic fingerprint mounted on an actuator, and some image recognition to know when to lower it onto the phone.
Same pattern works for logging into AWS from the console. My password manager keeps the username and password. Every time my AWS temporary session token expires, AWS CLI asks saml2aws for a new session token. Saml2aws gets user/password from the password manager, logs in. If session has expired, I get a pop-up on my phone asking me to log in. I supply fingerprint. Authentication is approved, and saml2aws creates a new session, passes it to AWS CLI, and I'm off to the races.
I can control exactly how often I have to enter in a password (to unlock my password manager), and the site administrator determines how long my sessions last. Is it super duper secure? No. But is it better than me typing my password, hitting submit, getting a text message, and typing a code in? Absolutely.
The same pattern can totally work across multiple sites. The standards just need to be changed to allow it to happen. This isn't a technical problem, it's a political one.