The easiest solution would be to refactor applications where possible, but if you cannot edit the source there are a few strategies:
"Middleman" password/account management solutions.
In this class of solutions, the actual password management is delegated to another service. The better solutions will be able to login to an application and change the password, then the password is changed by the application/service before each user logs in and is changed when the user logs out or time expires. In this way a password is produced for each individual and it has no value after the session because it has changed. If you want to research tools look for the class of "Privileged Identity Management" (PIM) tools.
Similar to a PIM solution, is a Privileged Access Management (PAM). Sometimes these tools are considered similar or a product may do both, but my definition of PAM is where the tool brokers the access for you. This article from Thycotic gives a brief look at terminology (warning from a Vendor)
Most of these services are designed for the OS level and are not always easy to configure with some type of cloud / SaaS service which has a workflow or 2FA.
Jump Box Solution
You may want to restrict access to authenticate to the service to a specific host. You then have strong authentication and logging on that host (maybe even record the screen). This may be sufficient for your needs depending on the apps and if you only need to do simple correlations to who was on the jump box to the application's logs. At the very least you can record all the activity. Some jumpbox+PAM solution may offer this through a web interface.
The weakness here is that you are not putting the control on the app, but at a lower level.
Proxy the authentication
If you are working with a popular cloud application, you may be able to find a CASB that you can put in front of your application and will enable the logging. The CASB may have the capability to do some form of PIM, pass a token, etc.
You may be able to setup some type of reverse proxy solution. OpenIAM describes such a setup for legacy applications - I have read about this before but we never got around to trying to implement it for a legacy application to which we had wanted to add SSO.
In your original post you talk about auto-filling forms. This still means the password could be intercepted or that two users could be authenticated at the same time if the web app does not prevent concurrent sessions. I would avoid anything that is like a end user password manager that just syncs the password files.
The ideal solution will make it so only one user can be on at a time and where an individual user either never sees the password of his version of the password becomes "one time" use.