You could create published datasources with the connection and initial SQL already defined. This could then be hosted on the server and it would make it more difficult to edit the connection, but not impossible.
Most of the methods I'm thinking through where you pass the tableau username could be interfered with by a user. I think ultimately if you need their actual db username to be in effect, they should be logging in with that username/password and not a common account.
It's that pesky "but not impossible" that the auditors don't like. The setup here is more like a web app where users are authenticated outside the database and access the database with a common account. The database has access to that external authentication to get and set a user's data labels with a logon trigger, but it's getting the auditor-acceptable correct username from Tableau that is tripping us up. Creating database accounts for thousands of users is likely the only secure way to get around this, but here there's little appetite for the Oracle account management overhead.
I agree with Tom. Also, you are right in that if auditors are concerned about "who sees what" then a better security mechanism is going to be needed and your thought of using db accounts is correct. Something to consider is setting up group accounts in the db, that way people are assigned to a db account group instead of having to manage thousands of individual accounts. However, you still can't stop people from sharing account credentials, nothing is bullet-proof
You do have a bit of a dilemma, it'd be interesting to see how you get this worked out.
You could publish your sources to the Tableau Server and remove the ability for users to download the datasource locally. Once it's published, your end users cannot change the initial SQL at all.