クライアントアプリケーションがデータベースサーバーに接続するときは、Unix コンピュータに特定のユーザーとしてログインするときと同じように、どの PostgreSQL ユーザー名で接続するかを指定します。SQL 環境の中では存在するデータベースユーザー名でデータベースオブジェクトへのアクセス権限が決まります。これに関しての詳しい情報は Chapter 7 を参照してください。ですから、あるクライアントがどのデータベースユーザー名でデータベースに接続できるかを制限することが根本的な要件であることは言うまでもありません。
認証 はデータベースサーバがクライアントの身元を識別し、その延長としてクライアントアプリケーション（もしくはクライアントアプリケーションを実行するユーザー）が要求されたユーザー名で接続することができるかどうかを決定する手順です。
PostgreSQL には異なったいくつかのクライアント認証方法があります。その中でどの方法を選択するかは（クライアントの）ホストとデータベースに依存します。認証方式の中にはユーザー名によって制限がかけられるものもあります。
PostgreSQL データベースのユーザー名は稼働しているサーバのオペレーティングシステムのユーザー名とは論理上関係が絶たれています。もし特定のサーバーのすべてのユーザーがサーバーマシン上にもアカウントを持っている場合、そのオペレーティングシステムのユーザー名に照合するデータベースユーザー名を割り当てることは理にかなっています。とはいっても、リモート接続を受け入れるサーバはそのコンピュータ上にアカウントを持たない多くのユーザーを抱えている場合もあって、そのような時にはデータベースユーザー名と Unix ユーザー名との間の関連性は必要ありません。
クライアント認証はデータディレクトリ、例えば /usr/local/pgsql/data/pg_hba.conf にある pg_hba.conf ファイルで管理されています。（HBA とは、host-based authentication：ホストベースの認証の略です。）デフォルトの pg_hba.conf ファイルはデータ領域が initdb で初期化される時にインストールされます。
pg_hba.conf ファイルの一般的なフォーマットは1 行 につき 1 つのレコードの集まりです。空行とハッシュ文字（"#"）で始まる行は無視されます。レコードはスペースもしくはタブで区切られたいくつかのフィールドで構成されています。レコードは行をまたいで続けることはできません。
それぞれのレコードは接続の形式、（接続形式にたいして意味を持つのであれば）クライアントの IP アドレス範囲、データベースの名前（複数も可）および、これらのパラメータと照合された接続に対し使用される認証方法を指定します。形式、クライアントアドレス、および接続要求を試みるデータベース名を照合する最初のレコードは認証処理に使用されます。"照合をずるずると継続"したり、 あるいは"バックアップ"を行うことはありません。これは、もしあるレコードが選択されて認証に失敗した場合、次のレコードは考慮されないということです。どのレコードも一致しない時はすべてのアクセスが拒否されます。
レコードのフォーマットは次の 3 つのうちのどれかになります。
local database authentication-method [ authentication-option ] host database IP-address IP-mask authentication-method [ authentication-option ] hostssl database IP-address IP-mask authentication-method [ authentication-option ]
フィールドの意味は以下のようになっています。
このレコードは Unix ドメインソケット経由の接続に対応します。
このレコードは TCP/IP ネットワーク経由の接続に対応します。ただし、サーバが -i オプション付で起動されているか、あるいは同等のパラメータが設定されていない限り、TCP/IP 接続はまったくできないことに注意してください。
このレコードは TCP/IP 経由の SSL を使った接続に対応します。このオプションを使うためには、サーバーは SSL サポートができるように構築されていなければいけません。さらに、SSL はサーバ起動時に -l オプション付、もしくは同等の設定がされていなければいけません。注意事項：host レコードは SSL でも非 SSL による接続試行にでも照合することがありますが、hostssl レコードは SSL 接続のみに一致します。
このレコードが適用されるデータベースを指定します。値としての all はそれがすべてのデータベースに適用されることを指定する一方、sameuser は接続ユーザーと同じ名前のデータベースを特定します。それ以外の場合には特定の PostgreSQL データベースの名前になります。
これらの 2 つのフィールドは、IP アドレスに基づいて、どのクライアントマシーンに host あるいは hostssl レコードを適用するかを指定します。（もちろん IP アドレスを偽ることができますが、このテーマを考慮するのは PostgreSQL の守備範囲外です。）詳細な考え方は以下のようになります。
この演算がゼロでないとレコードと照合されません。
ユーザーがこの認証用レコードの管理下でデータベースに接続する際に自分自身を認証するために使わなければならない方式を指定します。使用できる選択肢は下記のとおりですが、詳しくは Section 4.2 を参照してください。
接続は無条件で許可されます。この方式は、クライアントホストにログインできるすべてのユーザーに対して、 PostgreSQL のいかなるユーザーの接続も許可します。
接続は無条件に拒否されます。特定のホストをグループから "除外"するために大抵の場合便利です。
接続を試みる際にクライアントに、そのユーザー用に設定されたパスワードと照合するパスワードを要求します。
password キーワードの後に、オプションのファイル名を指定できます。指定するファイルには、このレコードを使って接続を行うユーザーの名前載っています。オプションとして代替パスワードも書いておけます。
パスワードは回線を通じて普通のテキスト形式で送られます。より確実に保護をかけるには md5 またはcrypt 方式を使ってください。
password 方式と似ていますが、パスワードは回線を通じ簡単なチャレンジレスポンスプロトコルで暗号化されて送られます。回線上でありがちな盗聴を防ぐことができます。現在、パスワードによる認証では選択肢として推奨されるものです。
md5 キーワードの後にこの名前のファイルが続くことがあります。このレコードを使って接続を行うユーザーの名前が載っています。
md5 方式と似ていますが 7.2 以前のクライアントが必要とする旧式の crypt 暗号化方式を使用します。7.2 以降のクライアントでは md5 の方が良いでしょう。crypt 方式は pg_shadow にある暗号化パスワードと互換ではありません。そしてクライアントとサーバが異なった crypt() ライブラリルーチンを実装していた場合失敗することがあります。
ユーザー認証に Kerberos V4 を使用します。TCP/IP 接続の時のみ有効です。
ユーザー認証に Kerberos V5 を使用します。TCP/IP 接続の時のみ有効です。
オペレーティングシステムにログインした時に特定されるユーザーの身元で、要求を受けるデータベースのユーザーとして接続を許可するかどうか PostgreSQL が使用します。TCP/IP 接続ではクライアントホスト上の ident サーバに尋ねることでユーザーの身元が特定されます。（この方式はリモートの ident サーバ程度の信頼性しかありません。管理者を信頼できないモートホストに対して ident 認証を決して行ってはいけません。）Unix ドメインソケットに対し SO_PEERCRED 要求をサポートしているオペレーティングシステム上では、ローカル接続に対してident 認証を使用することができます。システムはそこで接続しようとしているユーザーの身分を尋ねます。
SO_PEERCRED 要求のないシステム上では TCP/IP 接続に対してのみ ident 認証が使えます。使ってみるには localhost アドレス 127.0.0.1 を指定してこのアドレスに接続してください。
ident キーワードに続く authentication option はどのオペレーティングシステムユーザーがどのデータベースユーザーと等しいとされるのかを指定する ident map を指定します。詳細は以下です。
認証の形式は認証機構として PAM（Pluggable Authentication Modules）を使用することを除いて password のように働きます。 pam キーワードに続く authentication option は PAM に渡されるサービス名を指定します。デフォルトのサービス名は postgresql です。PAM についてより詳しくは Linux-PAM Page と Solaris PAM Page の両方かまたはどちらかを読んでください。
このフィールドは上で説明したように認証方式によって異なって解釈されます。
pg_hba.conf レコードは接続が試みられる度に逐次的に検査されます。レコードの順序はとても大切です。典型的には、始めのほうのレコードには厳しい接続照合パラメータと緩い照合方式があるのに対し、終りのほうのレコードにはより緩い照合パラメータとより厳しい認証方式があります。例えば、ローカル TCP 接続では trust 認証方式、リモート TCP 接続に対してはパスワードを要求したいとします。この場合、広範囲にわたって許可されるクライアントの IP アドレスに対するパスワード認証を指定するレコードの前に 127.0.0.1 からの接続に対する trust 認証指定のレコードが置かれなければなりません。
pg_hba.conf ファイルは起動時と、 postmaster が SIGHUP 信号を受け取ったときに読み込まれます。稼働中のシステムでファイルを編集した場合は、(pg_ctl reload あるいは kill -HUP を使用して) postmaster にファイルをもう一度読み込むように信号を出さなければなりません。
pg_hba.confファイルの一例を Example 4-1に示します。異なる認証メソッドの詳細についてはその後で説明します。
Example 4-1. pg_hba.conf ファイルの例
# TYPE DATABASE IP_ADDRESS MASK AUTHTYPE MAP
# ローカルシステム上のすべてのユーザーが、どのデータベースにどのユーザー名
# でも接続することを許可。但し IP 接続を通してのみ。
host all 127.0.0.1 255.255.255.255 trust
# Unix ソケット接続であることを除いて上記に同じ。
local all trust
# IP アドレス 192.168.93.x を持つすべてのホストのすべてのユーザーから
# データベース「template1」へ、そのホストの ident が身元確認したのと
# 同じユーザー名（典型的には Unix ユーザー名）で接続することを許可。
host template1 192.168.93.0 255.255.255.0 ident sameuser
# pg_shadowvの中のユーザーのパスワードが正しく与えられている場合
# ホスト 192.168.12.10 のユーザーからデータベース「template1」
# へ接続することを許可。
host template1 192.168.12.10 255.255.255.255 md5
# 先行する「host」行がなければ、これら 2 行によって（この項目が最初
# に照合されることから） 192.168.54.1 からの接続の試みをすべて拒否。
# 但し、インターネットのどこからでも Kerberos V5 で検証されている
# 接続は許可。ゼロマスクは、ホスト IP アドレスのビットを考慮せずに
# どのホストでも照合できることを意味する。
host all 192.168.54.1 255.255.255.255 reject
host all 0.0.0.0 0.0.0.0 krb5
# 192.168.x.x ホストからのユーザーが、ident チェックに通る場合、
# どのデータベースにでも接続を許可。もし、ident が「bryanh」と認定し
# 「bryanh」が PostgreSQL のユーザー「guest1」として
# 接続要求を出す場合、「bryanh」は「guest1」として接続が許可されますと
# いうマップ「omicron」に対する記載事項が pg_ident.conf にあれば接続を
# 許可。
host all 192.168.0.0 255.255.0.0 ident omicron
# ローカル接続に対してたった 2 行しか記載がない場合、ローカルユーザーは
# 自分のデータベース(ユーザー名と同じ名前のデータベース)のみ接続許可。
# 但し管理者はすべてのデータベースに接続可能。 $PGDATA/admins ファイル
# にはすべてのデータベースに対して接続を許されているユーザー名を所有。
# すべての場合にパスワードが必要。(ident 認証をしたい時は ident マップ
# によりここで使用されるパスワードリストのファイルに対し同時にこの方式
# を提供。)
local sameuser md5
local all md5 admins