There is a credible alternative that is available in corporate environments: LDAP (OpenDirectory), or Kerberos.

Well, let's see what we can make of this bold statement:

PostgreSQL can in fact authenticate against an LDAP server. This is documented in https://www.postgresql.org/docs/9.6/static/auth-methods.html (Note: Intentionally linking to 9.6, not current). But let's have a look at the documented details (emphasis mine):

20.3.7. LDAP Authentication

This authentication method operates similarly to password except that it uses LDAP as the password verification method. LDAP is used only to validate the user name/password pairs. Therefore the user must already exist in the database before LDAP can be used for authentication.

LDAP authentication can operate in two modes. In the first mode, which we will call the simple bind mode, the server will bind to the distinguished name constructed as prefix username suffix. [...]

In the second mode, which we will call the search+bind mode, the server [...] performs a search for the user trying to log in to the database. [...] Once the user has been found in this search, the server disconnects and re-binds to the directory as this user, using the password specified by the client, to verify that the login is correct. This mode is the same as that used by LDAP authentication schemes in other software, such as Apache mod_authnz_ldap and pam_ldap. This method allows for significantly more flexibility in where the user objects are located in the directory, but will cause two separate connections to the LDAP server to be made.

Or, summarized: PostgreSQL's LDAP authentication uses username and password passed to DBI->connect(). You have to provide username and password, no matter how you configure LDAP authentication.

This is how LDAP works, nicely summarized, and independent from the relational database engine used by DBI. In other words: LDAP can not help here. You have to provide a secret password to use LDAP.

Now, Kerberos. Quoting the same page:

20.3.3. GSSAPI Authentication

GSSAPI is an industry-standard protocol for secure authentication defined in RFC 2743. PostgreSQL supports GSSAPI with Kerberos authentication according to RFC 1964. GSSAPI provides automatic authentication (single sign-on) for systems that support it. [...]

GSSAPI support has to be enabled when PostgreSQL is built; see Chapter 16 for more information.

[...] Some Kerberos implementations might require a different service name, such as Microsoft Active Directory which requires the service name to be in upper case (POSTGRES).

[...]

So, yes, Kerberos can be used to avoid a password if the database supports it.

But: Does your database support it?

MySQL: LDAP, PAM, but no Kerberos. Windows authentication requires plugins on client and server, and won't help with non-Windows system. (And please don't make me think about clever ideas like "client-side cleartext authentication".) So, Kerberos won't help you with MySQL. FAIL.

MS SQL Server: Either pure Windows authentication, or Windows authentication alternatively to username/password stored in SQL server. Not even LDAP, and no trace of Kerberos. So: FAIL.

Oracle: LDAP, Kerberos, and many other. I did not expect less. PASS.

DB2: LDAP is supported, and Kerberos is, too. PASS.

PostgreSQL: see above. PASS.

Alexander

Just as general postgres authentication information (I don't think it's in any way applicable to the OP's question):

PostgreSQL 10 has scram authentication[1]

PostgreSQL 11 (expected fall 2018) adds channel binding to scram authentication [2]

[1] http://paquier.xyz/postgresql-2/postgres-10-scram-authentication/

[2] http://paquier.xyz/postgresql-2/postgres-11-scram-channel-binding/

Quick question: Can you authenticate in Kerberos only for "registered" scripts within a single Linux user?

Some code examples showing what you're talking about, like afoken provided, would be welcome. Otherwise skepticism may persist since you have demonstrated some confusion in this area.