I would not move authorization into AWS unless you want to spend hours debugging YAML & JSON blobs & templates, struggle with verification, and worse yet, transfer application superuser work onto devs & admins. (Edit: also forgot about core feature lock-in that has to be redone if you switch clouds)
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.
Neither authentication nor authorization is solved very well in general, although in some specific cases they are partially solved.
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).)
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)
The article has quite a bit of "me, me, me, I, I, I" self-promotional content. Which makes sense given it is an advertisement for his book.
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.
A very odd real example is how Sony went backwards with passkey compatibility on their apps. It's I think what happened when they tried to have a single OIDC setup instead of multiple (PSN was a totally separate setup for the longest time and had it solved, but other parts of Sony, on a separate system, was almost wholly incompatible. The merging of the two made it impossible for their current webkit implementations to detect passkeys in say your 1password when it was working like a charming for years on PSN). This kind of stuff happens but to put it into production when it's almost immediately obvious that they screwed up is pretty wild.
I would not move authorization into AWS unless you want to spend hours debugging YAML & JSON blobs & templates, struggle with verification, and worse yet, transfer application superuser work onto devs & admins. (Edit: also forgot about core feature lock-in that has to be redone if you switch clouds)
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.
Neither authentication nor authorization is solved very well in general, although in some specific cases they are partially solved.
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).)
This article says nothing.
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)
The article has quite a bit of "me, me, me, I, I, I" self-promotional content. Which makes sense given it is an advertisement for his book.
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.
Agreed, this is like the lead the horse to water issue. Yes the water exists, no one is really drinking it yet.
Yep, the king is currently SMS, which isn't good.
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.
A very odd real example is how Sony went backwards with passkey compatibility on their apps. It's I think what happened when they tried to have a single OIDC setup instead of multiple (PSN was a totally separate setup for the longest time and had it solved, but other parts of Sony, on a separate system, was almost wholly incompatible. The merging of the two made it impossible for their current webkit implementations to detect passkeys in say your 1password when it was working like a charming for years on PSN). This kind of stuff happens but to put it into production when it's almost immediately obvious that they screwed up is pretty wild.
“The most used passwords are love, sex, secret, and god” (Hackers, 1995)
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
If you solve authentication separately from authorization, this is what happens
If anyone has a good book on setting up a good authorization model in a corporate environment, please pass it along.
You just need a white list and a black list. Then conduct a background check to determine who is black and who's white. /s
Authorization has always been the primary question; authentication is simply an ancillary question to help answer it.