SASLは接続指向のプロトコルでの認証のためのフレームワークです。 現時点ではPostgreSQLは3つのSASLの認証機構、SCRAM-SHA-256、SCRAM-SHA-256-PLUS、OAUTHBEARERを実装しています。 将来には更に他の機構が追加されるかもしれません。 以下の手順は、SASLの認証が一般的にどのように行われるかを示したものですが、次の副節では特定の機構についてより詳細について説明します。
SASL認証のメッセージフロー
SASL認証の交換を開始するため、サーバはAuthenticationSASLメッセージを送信します。 これにはサーバが受け付けることができるSASLの認証機構を、サーバにとって望ましいものから順に並べたリストが含まれます。
クライアントはリストからサポートされる機構を1つ選択し、サーバにSASLInitialResponseメッセージを送信します。 このメッセージには選択された機構の名前が含まれ、また選択した機構がInitial Client Response（最初のクライアントの応答）を使用するなら、オプションでそれも含まれます。
サーバのチャレンジメッセージおよびクライアントのレスポンスメッセージが1つ以上続きます。 サーバのチャレンジはそれぞれがAuthenticationSASLContinueメッセージで送信され、それにクライアントからのレスポンスがSASLResponseメッセージで続きます。 メッセージの詳細は機構に固有のものです。
最後に、認証の交換が成功裏に終了すると、サーバはオプションのAuthenticationSASLFinalメッセージを送信し、その直後にAuthenticationOkメッセージを送信します。 AuthenticationSASLFinalにはサーバからクライアントへの追加のデータが含まれ、その内容は選択した認証機構毎に異なります。 完了時に送信する追加データを認証機構が使用していない場合、AuthenticationSASLFinalメッセージは送信されません。
エラーが発生したときは、サーバは認証を任意の段階で終了してErrorMessageを送信することができます。
SCRAM-SHA-256、およびそのチャネルバインディング版SCRAM-SHA-256-PLUS、はパスワードベースの認証メカニズムです。
RFC 7677およびRFC 5802で詳細に説明されています。
PostgreSQLでSCRAM-SHA-256を使用する場合、クライアントがclient-first-messageで送信するユーザ名をサーバは無視します。
その代わりに、開始メッセージで送信済みのユーザ名が使用されます。
SCRAMはユーザ名としてUTF-8の使用を指示していますが、PostgreSQLは複数の文字符号化方式をサポートするため、PostgreSQLのユーザ名をUTF-8で表現できないかもしれません。
SCRAMの仕様ではパスワードもUTF-8であり、SASLprepアルゴリズムで処理されることが規定されています。 しかしPostgreSQLではパスワードにUTF-8が使用されることを必須としていません。 ユーザのパスワードが設定されたとき、実際に使用された符号化方式に関わらず、それがUTF-8であるかのようにSASLprepで処理されます。 しかし、それが正当なUTF-8バイト列でない場合、あるいはSASLprepが禁止するUTF-8バイト列を含む場合、エラーを発生させるのではなく、SASLprep処理のない生のパスワードが使用されます。 これにより、パスワードがUTF-8であればそれを正規化できる一方で、UTF-8以外のパスワードを使用することもでき、またシステムもパスワードがどの符号化であるかを知る必要もありません。
SSLをサポートするPostgreSQLビルドでチャネルバインディングがサポートされます。
チャネルバインディングを伴うSCRAMに対するSASL機構名はSCRAM-SHA-256-PLUSです。
PostgreSQLで使われるチャネルバインディングのタイプはtls-server-end-pointです。
チャネルバインディングを伴わないSCRAMではサーバは、送信されるパスワードハッシュの中でユーザに応じたパスワードと混合してクライアントに送る乱数を選びます。 これはパスワードハッシュが後のセッションで再送信されて認証に成功してしまうことを防止しますが、真のサーバとクライアントの間の偽サーバがサーバのランダム値を中継して認証に成功してしまうことを防止しません。
チャネルバインディングを伴うSCRAMはこのような中間者攻撃をサーバ証明書のシグネチャを送信されるパスワードハッシュと混合することで防止します。 偽サーバは真のサーバの証明書を再送信できますが、その証明書に一致する秘密鍵にアクセスできず、それゆえ所有者であることを証明できず、結果としてSSL接続は失敗します。
例
サーバはAuthenticationSASLメッセージを送信します。
それにはサーバが受け付けることができるSASL認証機構のリストが含まれます。
サーバがSSLサポート有でビルドされていれば、これはSCRAM-SHA-256-PLUSとSCRAM-SHA-256になり、そうでなければ後者のみとなります。
クライアントはSASLInitialResponseメッセージを送信することで応答します。
これは選択した機構、すなわちSCRAM-SHA-256またはSCRAM-SHA-256-PLUSを示します。
（クライアントは何れかの機構を自由に選びますが、より良いセキュリティのためサポートされているならチャネルバインディングを伴うものを選ぶべきです。）
Initial Clientの応答フィールドでは、メッセージにSCRAMのclient-first-messageが含まれます。
client-first-messageにはクライアントが選んだチャネルバインディングのタイプも含まれます。
サーバがAuthenticationSASLContinueメッセージを送信します。
その内容はSCRAMのserver-first-messageです。
クライアントがSASLResponseメッセージを送信します。
その内容はSCRAMのclient-final-messageです。
サーバがSCRAMのserver-final-messageを含むAuthenticationSASLFinalメッセージを送信し、その直後にAuthenticationOkメッセージを送信します。
OAUTHBEARERは、トークンベースのフェデレーション認証のメカニズムです。
詳細はRFC 7628に記載されています。
典型的な交換は、クライアントがそのユーザ用にキャッシュされたベアラ（bearer）トークンをすでに持っているかどうかによって異なります。 持っていない場合、交換は2つの接続で行われます。 最初の「ディスカバリ」コネクションはサーバからOAuthメタデータを取得し、2番目のコネクションはクライアントがそれを取得した後にトークンを送信します。 （libpqは現在、組み込みフローの一部としてキャッシングメソッドを実装していないため、2つのコネクション交換を使用します。）
このメカニズムは、SCRAMと同様にクライアント主導型です。
クライアント初期応答は、SCRAMで使用される標準の「GS2」ヘッダと、それに続くkey=valueペアのリストで構成されます。
現在サーバでサポートされている唯一のキーはauthで、ベアラトークンを含んでいます。
さらにOAUTHBEARERは、クライアント初期応答の3つのオプショナルコンポーネント（GS2ヘッダのauthzidと、現在サーバで無視されているhostおよびportキー）を指定します。
OAUTHBEARERチャネルバインディングをサポートしておらず、「OAUTHBEARER-PLUS」メカニズムもありません。
このメカニズムは、認証の成功時にサーバデータを使用しないため、AuthenticationSASLFinalメッセージはやり取りで使用されません。
例
最初のやり取りでは、サーバはAuthenticationSASLメッセージをOAUTHBEARERメカニズムを表示して送信します。
クライアントは、OAUTHBEARERメカニズムを示すSASLInitialResponseメッセージを送信することで応答します。
クライアントはまだ現在のユーザの有効なベアラトークンを持っていないものと見なすので、authフィールドは空であり、これはディスカバリコネクションを意味します。
サーバは、エラーstatusを含むAuthenticationSASLContinueメッセージをクライアントがOAuthフローを実行するために使用するよく知られたURIとスコープとともに送信します。
クライアントは、空のセット（単一の0x01バイト）を含むSASLResponseメッセージを送信して、ディスカバリ交換の半分を終了します。
サーバはErrorMessageを送信して最初のやり取りを失敗させます。
この時点で、クライアントはサーバによって提供されるものに加えて、設定されている任意のメタデータを使用して、ベアラトークンを取得するために多くの可能なOAuthフローの1つを実行します。
（この説明は意図的に曖昧にされています。OAUTHBEARERはトークンを取得するための特定のメソッドを指定または義務付けていません。）
クライアントはトークンを所有すると、最終的なやり取りのためにサーバに再接続します。
サーバは再びAuthenticationSASLメッセージをOAUTHBEARERメカニズムを表示して送信します。
クライアントはSASLInitialResponseメッセージを送信することで応答しますが、今回はメッセージ中のauthフィールドはクライアントフロー中に取得されたベアラトークンを含みます。
サーバは、トークンプロバイダの指示に従ってトークンを検証します。 クライアントが接続を認可されている場合は、AuthenticationOkメッセージを送信してSASL交換を終了します。