Authentication Is Largely Solved. Authorization Isn't(technometria.com) |
Authentication Is Largely Solved. Authorization Isn't(technometria.com) |
In practice, operationally, none of this is solved. Every website/app/platform handles logins differently. Some are still doing SMS 2FA, some still do passwords, some implemented passkeys in the wrong way, some are doing app based MFA, some are doing magic links, some are doing email codes.
You can't in good faith say this is "solved" when it's just more complicated than ever, and the UX is terrible (passkeys, cough)
I find it jarring to hear that authentication is "largely solved" by passkeys and FIDO, technology that a very very small minority of applications support. Making claims like this combined with the focus on self-promotion is a quick path to being dismissed and ignored.
I like passkeys, but somewhere between websites and browsers, even those aren't used in a consistent way. And idk why there are so many prompts before you're actually logged in with one. The name is also unclear.
TOTP is way worse. It used to be kinda synonymous with Google Authenticator which had insane footguns for losing your codes. Now it's just inconsistent and weird. Like I was trying to set up Github 2FA with 1password, it wanted me to scan a QR code with the browser extension, that wasn't working, so I had to copy some other code instead and paste it into some deep hidden menu of 1password that I needed a tutorial to find. I almost did SMS instead. Most people probably will.
Also don't know why Github requires TOTP or SMS even if you already have a passkey. Probably goes back to passkeys not being mature yet.
For working on a single computer, I think capability-based security with proxy capabilities is helpful for both. This won't do alone; however, you can add a user account database and you can handle permissions made out of such a capability-based security, which can be flexible because each process can have different permissions, and with proxy capabilities it is possible for the permissions to do things other than the fixed set of permissions.
For working on multiple computers, I think X.509 certificate chains is helpful for both. You can check that the user can authenticate with the key in the end certificate, and can look in the certificate chain for a recognized authority and know what permissions it has, and then check if the required permissions are granted either by all certificates leading to and including the end certificate, or only the end certificate, depending on the type of permissions (e.g. extended key usage might only be needed by the end certificate, while such things as what files it is allowed to access and how it can access them must be permitted by the entire chain in order to be granted). Extensions can be added to specify any additional details required by the authorization and/or authentication needed by your application. (The use of X.509 certificate chains also means that you would not need API keys, nor passwords (the private key can be passworded if you want to, but the server never sees the password, and therefore cannot steal it).)
Having a user interface where trusted users can assign privileges to lower-level folks is massively advantageous if you build it right, by comparison. You do need to make fine-grained control possible, to be able to roll up permission sets into predefined roles, and - a simple matter that evades many - assign multiple roles to a given user. Users frequently "wear multiple hats", as they say, and you need to account for that.
Clearly the problem is solved now:
“Minimum of 6 characters please”
bullet ricochet noises
“Special character please”
ninja roll
“I’M GONNNA NEED TO SEE SOME ID”
nuclear explosion