当trust认证被指定时，UXDB假设任何可以连接到服务器的人都被授权使用他们指定的任何数据库用户名（即使是超级用户）访问数据库。当然，在database和 user列中设置的限制仍然适用。只有当在操作系统层对进入服务器的连接有足够保护时，才可以使用这种方法。

trust认证对于单用户工作站的本地连接是非常合适和方便的。通常它本身不适用于一台多用户机器。不过，只要你利用文件系统权限限制了对服务器的Unix域套接字文件的访问，即使在多用户机器上，你也可以使用trust。要做这些限制，你可以设置第?3.3?节中描述的unix_socket_permissions配置参数（可能还有unix_socket_group）。或者你可以设置unix_socket_directories配置参数来把Unix域套接字文件放在一个经过恰当限制的目录中。

设置文件系统权限只能有助于Unix套接字连接。本地TCP/IP连接不会被文件系统权限限制。因此，如果你想利用文件系统权限来控制本地安全，那么从ux_hba.conf中移除host ... 127.0.0.1 ...是可行的，或者把它改为一个非trust认证方法。

如果通过指定trust的ux_hba.conf行让你信任每一个被允许连接到服务器的机器上的用户，trust认证只适合TCP/IP连接。为任何不是来自localhost（127.0.0.1）的TCP/IP连接使用trust很少是合理的。

有几种基于口令的身份验证方法。这些方法的操作方式相似， 但在服务器上存储用户密码的方式以及客户端提供的密码如何通过连接发送方面有所不同。

UXDB数据库口令独立于操作系统用户口令。每个数据库用户的口令被存储在ux_authid系统目录中。口令可以用SQL命令CREATE USER和ALTER ROLE管理，例如CREATE USER foo WITH PASSWORD 'secret'， 或者uxsql命令\password。如果没有为一个用户设置口令，那么存储的口令为空并且对该用户的口令认证总会失败。

不同的基于密码的身份验证方法的可用性取决于用户的密码在服务器上是如何加密的 （或更准确地说是哈希）。这是在设置密码时由配置参数 password_encryption控制的。如果使用 scram-sha-256设置对密码进行了加密， 那么它可以用于身份验证方法scram-sha-256和password （但在后一种情况下密码传输将以纯文本形式）。如上所述， 认证方法规范md5会自动切换到使用scram-sha-256方法， 所以它也可以工作。如果密码是使用md5设置加密的， 那么它只能用于md5和password认证方法规范 （同样，在后一种情况下用明文传输密码）。要查看当前存储的密码哈希值，请查看系统目录ux_authid。

在确保所有正在使用的客户端库足够新以支持SCRAM后， 要将现有安装从md5升级到scram-sha-256， 在uxsinodb.conf中设置 password_encryption = 'scram-sha-256'， 让所有用户设置新密码，并将ux_hba.conf 中的认证方法声明更改为scram-sha-256。

GSSAPI是用于RFC 2743中定义的安全认证的一个工业标准协议。UXDB根据RFC 1964支持带Kerberos认证的GSSAPI。GSSAPI为支持它的系统提供自动认证（单点登录）。认证本身是安全的，但通过数据库连接发送的数据将不被加密，除非使用SSL。

当编译UXDB时，GSSAPI支持必须被启用。

当GSSAPI使用Kerberos时， 它会使用格式为 servicename/hostname@realm的标准 principal。 UXDB服务器将接受该服务器所使用的keytab中包括的任何principal，但是在从使用 krbsrvname连接参数的客户端建立连接时要注意指定正确的principal细节。安装的默认值uxdb 可以在编译时使用 ./configure --with-krb-srvnam=其他值修改。 在大部分的环境中，这个参数从不需要被更改。某些Kerberos实现可能要求一个不同的服务名， 例如Microsoft Active Directory要求服务名是大写形式（UXDB）。

hostname是服务器机器的被完全限定的主机名。服务principal的realm是该服务器机器的首选 realm。

客户端principal可以被通过ux_ident.conf映射到不同的 UXDB数据库用户名。例如， uxusername@realm可能会被映射到uxusername。 或者，你可以使用完整的username@realm当事人作为 UXDB中的角色而无需任何映射。

UXDB也支持一个参数把realm从principal中剥离。不建议使用它，因为这样就无法区分具有相同用户名却来自不同realm的不同用户了。要启用这种方法，可将include_realm设置为0。对于简单的单realm安装，这样做并且设置krb_realm参数（这会检查principal的realm是否正好匹配krb_realm中的参数）仍然是安全的。但比起在ux_ident.conf中指定一个显式映射来说，这种方法的能力较低。

确认你的服务器的keytab文件是可以被UXDB服务器帐 户读取的（最好是只读的） 。密钥文件的位置由配置 参数krb_server_keyfile指定。默认是/usr/local/uxsql/etc/krb5.keytab（或者任何在编译的时候作为sysconfdir的目录）。 出于安全原因，推荐对UXDB服务器使用一个独立 的keytab而不是开放系统keytab文件的权限。

keytab文件由Kerberos软件生成。下面是MIT兼容的Kerberos 5实现的例子：

kadmin% ank -randkey uxdb/server.my.domain.org
kadmin% ktadd -k krb5.keytab uxdb/server.my.domain.org

当连接到数据库时，确保你有一个匹配被请求数据库用户名的principal的票据。例如，对于数据库用户名fred，principal fred@EXAMPLE.COM将能够连接。要也允许principal fred/users.example.com@EXAMPLE.COM，可使用一个用户名映射，如第?4.2?节中所述。

下列配置选项被支持用于GSSAPI：

SSPI是一种用于带单点登录的安全认证的Windows技术。 UXDB在negotiate模式中将使用 SSPI，它在可能的情况下使用Kerberos并在其他情况下自动降回到NTLM。只有在服务器和客户端都运行着Windows时，SSPI才能工作。或者在非Windows平台上GSSAPI可用时，SSPI也能工作。

当使用Kerberos认证时，SSPI和GSSAPI的工作方式相同，详见第?4.3.3?节。

下列配置选项被支持用于SSPI：

ident认证方法通过从一个ident服务器获得客户端的操作系统用户名并且用它作为被允许的数据库用户名（和可选的用户名映射）来工作。它只在TCP/IP连接上支持。

下列配置选项被支持用于ident：

“Identification Protocol（标识协议）”在RFC 1413中描述。实际上每个类Unix操作系统都带着一个默认监听TCP 113端口的ident服务器。ident服务器的基本功能是回答类似这样的问题：“哪个用户从你的端口X发起了连接并且连到了澳门游戏平台注册网站的端口Y？” 。因为当一个物理连接被建立后，UXDB既知道X也知道Y，所以它可以询问尝试连接的客户端主机上的ident服务器并且在理论上可以判断劝拿庞蜗菲教ㄗ⒉嵬锯给定连接的操作系统用户。

这个过程的缺点是它依赖于客户端的完整性：如果客户端机器不可信或者被攻破，攻击者可能在113端口上运行任何程序并且返回他们选择的任何用户。因此这种认证方法只适用于封闭的网络， 这样的网络中的每台客户端机器都处于严密的控制下并且数据库和操作系统管理员操作时可以方便地联系。换句话说，你必须信任运行ident服务器的机器。注意这样的警告：

有些ident服务器有一个非标准的选项，它导致返回的用户名是被加密的，使用的是只有原机器管理员知道的一个密钥。当与UXDB配合使用ident服务器时，一定不要使用这个选项，因为UXDB没有任何方法对返回的字符串进行解密以获取实际的用户名。

peer认证方法通过从内核获得客户端的操作系统用户名并使用它作为允许的数据库用户名（使用可选的用户名映射）工作。这个方法只支持本地连接。

下列配置选项被支持用于peer：

Peer认证只在提供getpeereid()函数、SO_PEERCRED套接字参数或相似机制的操作系统上可用。这些OS当前包括Linux、大部分的BSD包括macOS以及Solaris。

这种认证方法操作起来类似于password， 只不过它使用LDAP作为密码验证方法。LDAP只被用于验证用户名/口令对。因此，在使用LDAP进行认证之前，用户必须已经存在于数据库中。

LDAP认证可以在两种模式下操作。在第一种模式中（称为简单绑定模式），服务器将绑定到以prefix username suffix构造的识别名（Distinguished Name）上。通常prefix参数用于在活跃目录环境中指定cn=或DOMAIN\。suffix用来在非活跃目录环境中指定DN的剩余部分。

在第二种模式中（称为搜索与绑定模式），服务器首先用一个固定的用户名和密码（用ldapbinddn和ldapbindpasswd指定）绑定到LDAP目录 ，并为试图登入该数据库的用户执行一次搜索。如果没有配置用户名和密码，将尝试一次匿名绑定到目录。搜索将在位于ldapbasedn的子树上被执行，并将尝试做一次ldapsearchattribute中指定属性的精确匹配。一旦在这次搜索中找到用户，服务器断开并且作为这个用户重新绑定到目录，使用由客户端指定的口令来验证登录是正确的。这种模式与在其他软件中的LDAP认证所使用的相同，例如Apache mod_authnz_ldap和pam_ldap。这种方法允许位于目录中用户对象的更大灵活性，但是会导致建立两个到LDAP服务器的独立连接。

下列配置选项被用于两种模式：

下列选项只被用于简单绑定模式：

下列选项只被用于搜索与绑定模式：

将简单绑定的选项中混合用于搜索与绑定的选项是错误的。

这里是一个简单绑定LDAP配置的例子：

host ... ldap ldapserver=ldap.example.net ldapprefix="cn=" ldapsuffix=", dc=example, dc=net"

当请求一个作为数据库用户someuser到数据库服务器的连接时，UXDB将尝试使用cn=someuser, dc=example, dc=net和客户端提供的口令来绑定到LDAP服务器。如果那个连接成功，将被授予数据库访问。

这里是一个搜索与绑定配置的例子：

host ... ldap ldapserver=ldap.example.net ldapbasedn="dc=example, dc=net" ldapsearchattribute=uid

当请求一个作为数据库用户someuser到数据库服务器的连接时，UXDB将尝试匿名绑定（因为没有指定ldapbinddn）到LDAP服务器，在指定的基础DN下执行一次对于(uid=someuser)的搜索。如果找到一个项，则它将尝试使用找到的信息和客户端提供的口令进行绑定。如果第二个连接成功，将被授予数据库访问。

这里是被写成一个URL的相同搜索与绑定配置：

host ... ldap ldapurl="ldap://ldap.example.net/dc=example,dc=net?uid?sub"

一些支持根据LDAP认证的其他软件使用相同的URL格式，因此很容易共享该配置。

这种认证方法的操作类似于password，不过它使用RADIUS作为密码验证方式。RADIUS只被用于验证用户名/密码对。因此，在RADIUS被用于认证之前，用户必须已经存在于数据库中。

当使用RADIUS认证时，一个访问请求消息将被发送到配置好的RADIUS服务器。这一请求将是Authenticate Only类型，并且包含参数user name、password（加密的）和NAS Identifier。该请求将使用一个与服务器共享的密钥加密。RADIUS服务器将对这个服务器响应Access Accept或者Access Reject。不支持RADIUS账户。

可以指定多个RADIUS服务器，在这种情况下，它们将按顺序尝试。如果从服务器收到否定响应，则认证将失败。如果未收到响应，则会尝试列表中的下一台服务器。要指定多个服务器，请将名称放在引号内，并用逗号分隔服务器名称。如果指定了多个服务器， 则所有其他RADIUS选项也可以以逗号分隔的列表提供以将各个值应用于每个服务器。也可以指定为单个值，在这种情况下，此值将应用于所有服务器。

RADIUS支持下列的配置选项：

这个认证方法使用SSL客户端证书来执行认证。因此只适用于SSL连接。当使用这个认证方法时，服务器将请求客户端提供一个有效的证书。没有密码提示发送给客户端。证书的cn（Common Name-通用名）属性将与请求的数据库用户名比较，如果它们匹配，登录将被允许。用户名映射可以用来允许cn不同于数据库用户名。

SSL证书认证支持下列的配置选项：

在一条指定证书认证的ux_hba.conf记录中，认证选项clientcert被假定为1，并且它不能被关掉，因为这种方法中一个客户端证书是必需的。cert方法对基本clientcert证书验证测试所增加的东西是检查cn属性是否匹配数据库用户名。

这种认证方法操作起来类似password，只不过它使用PAM（Pluggable Authentication Modules-插入式验证模块）作为认证机制。默认的PAM服务名是uxdb。PAM只被用于验证用户名/口令对并且可以有选择地验证已连接的远程主机名或IP地址。因此，在使用PAM进行认证之前，用户必须已经存在于数据库中。有关PAM的更多信息，请阅读Linux-PAM页面.

PAM支持下列的配置选项：

这种认证方法操作起来类似于password，不过它使用BSD认证来验证口令。BSD认证只被用来验证用户名/密码对。因此，在BSD认证可以被用于认证之前，用户的角色必须已经存在于数据库中。BSD认证框架当前只在OpenBSD上可用。

UXDB中的BSD认证使用auth-uxsql登录类型，如果login.conf中定义了uxdb登录分类，就会用它来认证。默认情况下这种登录分类不存在，UXDB将使用默认的登录分类。