Authentication Is Largely Solved. Authorization Isn't

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.

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)

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).)

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.

Authorization has always been the primary question; authentication is simply an ancillary question to help answer it.