<firstterm>SASL</firstterm> is a framework for authentication in connection-oriented protocols. At the moment, <productname>PostgreSQL</productname> implements three SASL authentication mechanisms: SCRAM-SHA-256, SCRAM-SHA-256-PLUS, and OAUTHBEARER. More might be added in the future. The below steps illustrate how SASL authentication is performed in general, while the next subsections give more details on particular mechanisms. 《マッチ度[81.438515]》SASLは接続指向のプロトコルでの認証のためのフレームワークです。 現時点ではPostgreSQLは2つのSASLの認証機構、SCRAM-SHA-256とSCRAM-SHA-256-PLUSを実装しています。 将来には他の機構が追加されるかもしれません。 以下の手順は、SASLの認証が一般的にどのように行われるかを示したものですが、次の副節ではSCRAM-SHA-256とSCRAM-SHA-256-PLUSにおけるより詳細について説明します。 《機械翻訳》SASLは、コネクション指向のプロトコルにおける認証のフレームワークです。 現在、PostgreSQLは、SCRAM-SHA-256、SCRAM-SHA-256-プラス、およびOAUTHBEARERの3つのSASL認証メカニズムを実装しています。 将来、さらに追加される可能性があります。 次の手順では、SASL認証が一般的にどのように実行されるかを示します。 一方、次のサブセクションでは、特定のメカニズムの詳細を示します。
SASL認証のメッセージフロー
<title>SASL Authentication Message Flow</title>To begin a SASL authentication exchange, the server sends an AuthenticationSASL message. It includes a list of SASL authentication mechanisms that the server can accept, in the server's preferred order. SASL認証の交換を開始するため、サーバはAuthenticationSASLメッセージを送信します。 これにはサーバが受け付けることができるSASLの認証機構を、サーバにとって望ましいものから順に並べたリストが含まれます。
The client selects one of the supported mechanisms from the list, and sends a SASLInitialResponse message to the server. The message includes the name of the selected mechanism, and an optional Initial Client Response, if the selected mechanism uses that. クライアントはリストからサポートされる機構を1つ選択し、サーバにSASLInitialResponseメッセージを送信します。 このメッセージには選択された機構の名前が含まれ、また選択した機構がInitial Client Response（最初のクライアントの応答）を使用するなら、オプションでそれも含まれます。
One or more server-challenge and client-response message will follow. Each server-challenge is sent in an AuthenticationSASLContinue message, followed by a response from client in a SASLResponse message. The particulars of the messages are mechanism specific. サーバのチャレンジメッセージおよびクライアントのレスポンスメッセージが1つ以上続きます。 サーバのチャレンジはそれぞれがAuthenticationSASLContinueメッセージで送信され、それにクライアントからのレスポンスがSASLResponseメッセージで続きます。 メッセージの詳細は機構に固有のものです。
Finally, when the authentication exchange is completed successfully, the server sends an optional AuthenticationSASLFinal message, followed immediately by an AuthenticationOk message. The AuthenticationSASLFinal contains additional server-to-client data, whose content is particular to the selected authentication mechanism. If the authentication mechanism doesn't use additional data that's sent at completion, the AuthenticationSASLFinal message is not sent. 《マッチ度[90.434783]》最後に、認証の交換が成功裏に終了すると、サーバはAuthenticationSASLFinalメッセージを送信し、その直後にAuthenticationOkメッセージを送信します。 AuthenticationSASLFinalにはサーバからクライアントへの追加のデータが含まれ、その内容は選択した認証機構毎に異なります。 完了時に送信する追加データを認証機構が使用していない場合、AuthenticationSASLFinalメッセージは送信されません。
On error, the server can abort the authentication at any stage, and send an ErrorMessage. エラーが発生したときは、サーバは認証を任意の段階で終了してErrorMessageを送信することができます。
<literal>SCRAM-SHA-256</literal>, and its variant with channel
binding <literal>SCRAM-SHA-256-PLUS</literal>, are password-based
authentication mechanisms. They are described in
detail in <ulink url="https://datatracker.ietf.org/doc/html/rfc7677">RFC 7677</ulink>
and <ulink url="https://datatracker.ietf.org/doc/html/rfc5802">RFC 5802</ulink>.
《マッチ度[65.988372]》今のところ実装されているSASL機構はSCRAM-SHA-256とチャネルバインディングを伴う変種のSCRAM-SHA-256-PLUSです。
詳細はRFC 7677およびRFC 5802で説明されています。
《機械翻訳》SCRAM-SHA-256、およびそのチャネルバインディング版SCRAM-SHA-256-PLUS、はパスワードベースの認証メカニズムです。
RFC 7677およびRFC 5802で詳細に説明されています。
When SCRAM-SHA-256 is used in PostgreSQL, the server will ignore the user name
that the client sends in the <structname>client-first-message</structname>. The user name
that was already sent in the startup message is used instead.
<productname>PostgreSQL</productname> supports multiple character encodings, while SCRAM
dictates UTF-8 to be used for the user name, so it might be impossible to
represent the PostgreSQL user name in UTF-8.
PostgreSQLでSCRAM-SHA-256を使用する場合、クライアントがclient-first-messageで送信するユーザ名をサーバは無視します。
その代わりに、開始メッセージで送信済みのユーザ名が使用されます。
SCRAMはユーザ名としてUTF-8の使用を指示していますが、PostgreSQLは複数の文字符号化方式をサポートするため、PostgreSQLのユーザ名をUTF-8で表現できないかもしれません。
The SCRAM specification dictates that the password is also in UTF-8, and is processed with the <firstterm>SASLprep</firstterm> algorithm. <productname>PostgreSQL</productname>, however, does not require UTF-8 to be used for the password. When a user's password is set, it is processed with SASLprep as if it was in UTF-8, regardless of the actual encoding used. However, if it is not a legal UTF-8 byte sequence, or it contains UTF-8 byte sequences that are prohibited by the SASLprep algorithm, the raw password will be used without SASLprep processing, instead of throwing an error. This allows the password to be normalized when it is in UTF-8, but still allows a non-UTF-8 password to be used, and doesn't require the system to know which encoding the password is in. SCRAMの仕様ではパスワードもUTF-8であり、SASLprepアルゴリズムで処理されることが規定されています。 しかしPostgreSQLではパスワードにUTF-8が使用されることを必須としていません。 ユーザのパスワードが設定されたとき、実際に使用された符号化方式に関わらず、それがUTF-8であるかのようにSASLprepで処理されます。 しかし、それが正当なUTF-8バイト列でない場合、あるいはSASLprepが禁止するUTF-8バイト列を含む場合、エラーを発生させるのではなく、SASLprep処理のない生のパスワードが使用されます。 これにより、パスワードがUTF-8であればそれを正規化できる一方で、UTF-8以外のパスワードを使用することもでき、またシステムもパスワードがどの符号化であるかを知る必要もありません。
<firstterm>Channel binding</firstterm> is supported in PostgreSQL builds with
SSL support. The SASL mechanism name for SCRAM with channel binding is
<literal>SCRAM-SHA-256-PLUS</literal>. The channel binding type used by
PostgreSQL is <literal>tls-server-end-point</literal>.
SSLをサポートするPostgreSQLビルドでチャネルバインディングがサポートされます。
チャネルバインディングを伴うSCRAMに対するSASL機構名はSCRAM-SHA-256-PLUSです。
PostgreSQLで使われるチャネルバインディングのタイプはtls-server-end-pointです。
In <acronym>SCRAM</acronym> without channel binding, the server chooses a random number that is transmitted to the client to be mixed with the user-supplied password in the transmitted password hash. While this prevents the password hash from being successfully retransmitted in a later session, it does not prevent a fake server between the real server and client from passing through the server's random value and successfully authenticating. チャネルバインディングを伴わないSCRAMではサーバは、送信されるパスワードハッシュの中でユーザに応じたパスワードと混合してクライアントに送る乱数を選びます。 これはパスワードハッシュが後のセッションで再送信されて認証に成功してしまうことを防止しますが、真のサーバとクライアントの間の偽サーバがサーバのランダム値を中継して認証に成功してしまうことを防止しません。
<acronym>SCRAM</acronym> with channel binding prevents such man-in-the-middle attacks by mixing the signature of the server's certificate into the transmitted password hash. While a fake server can retransmit the real server's certificate, it doesn't have access to the private key matching that certificate, and therefore cannot prove it is the owner, causing SSL connection failure. チャネルバインディングを伴うSCRAMはこのような中間者攻撃をサーバ証明書のシグネチャを送信されるパスワードハッシュと混合することで防止します。 偽サーバは真のサーバの証明書を再送信できますが、その証明書に一致する秘密鍵にアクセスできず、それゆえ所有者であることを証明できず、結果としてSSL接続は失敗します。
例
<title>Example</title>
The server sends an AuthenticationSASL message. It includes a list of
SASL authentication mechanisms that the server can accept.
This will be <literal>SCRAM-SHA-256-PLUS</literal>
and <literal>SCRAM-SHA-256</literal> if the server is built with SSL
support, or else just the latter.
サーバはAuthenticationSASLメッセージを送信します。
それにはサーバが受け付けることができるSASL認証機構のリストが含まれます。
サーバがSSLサポート有でビルドされていれば、これはSCRAM-SHA-256-PLUSとSCRAM-SHA-256になり、そうでなければ後者のみとなります。
The client responds by sending a SASLInitialResponse message, which
indicates the chosen mechanism, <literal>SCRAM-SHA-256</literal> or
<literal>SCRAM-SHA-256-PLUS</literal>. (A client is free to choose either
mechanism, but for better security it should choose the channel-binding
variant if it can support it.) In the Initial Client response field, the
message contains the SCRAM <structname>client-first-message</structname>.
The <structname>client-first-message</structname> also contains the channel
binding type chosen by the client.
クライアントはSASLInitialResponseメッセージを送信することで応答します。
これは選択した機構、すなわちSCRAM-SHA-256またはSCRAM-SHA-256-PLUSを示します。
（クライアントは何れかの機構を自由に選びますが、より良いセキュリティのためサポートされているならチャネルバインディングを伴うものを選ぶべきです。）
Initial Clientの応答フィールドでは、メッセージにSCRAMのclient-first-messageが含まれます。
client-first-messageにはクライアントが選んだチャネルバインディングのタイプも含まれます。
Server sends an AuthenticationSASLContinue message, with a SCRAM
<structname>server-first-message</structname> as the content.
サーバがAuthenticationSASLContinueメッセージを送信します。
その内容はSCRAMのserver-first-messageです。
Client sends a SASLResponse message, with SCRAM
<structname>client-final-message</structname> as the content.
クライアントがSASLResponseメッセージを送信します。
その内容はSCRAMのclient-final-messageです。
Server sends an AuthenticationSASLFinal message, with the SCRAM
<structname>server-final-message</structname>, followed immediately by
an AuthenticationOk message.
サーバがSCRAMのserver-final-messageを含むAuthenticationSASLFinalメッセージを送信し、その直後にAuthenticationOkメッセージを送信します。
<literal>OAUTHBEARER</literal> is a token-based mechanism for federated
authentication. It is described in detail in
<ulink url="https://datatracker.ietf.org/doc/html/rfc7628">RFC 7628</ulink>.
《機械翻訳》OAUTHBEARERは、トークンを拠点とする認証連合のメカニズムです。
詳細はRFC 7628に記載されています。
A typical exchange differs depending on whether or not the client already has a bearer token cached for the current user. If it does not, the exchange will take place over two connections: the first "discovery" connection to obtain OAuth metadata from the server, and the second connection to send the token after the client has obtained it. (libpq does not currently implement a caching method as part of its builtin flow, so it uses the two-connection exchange.) 《機械翻訳》一般的な交換は、クライアントがすでに現在トークン用にキャッシュされたベアラユーザを持っているかどうかによって異なります。 持っていない場合、交換は2つの接続で行われます。 最初の「ディスカバリ」コネクションはサーバからOAuthメタデータを取得し、2番目のコネクションはクライアントがそれを取得した後にトークンを送信します（libpqは現在、組み込みフローのパートとしてキャッシングメソッドを実装していないため、2つのコネクション交換を使用します）。
This mechanism is client-initiated, like SCRAM. The client initial response
consists of the standard "GS2" header used by SCRAM, followed by a list of
<literal>key=value</literal> pairs. The only key currently supported by
the server is <literal>auth</literal>, which contains the bearer token.
<literal>OAUTHBEARER</literal> additionally specifies three optional
components of the client initial response (the <literal>authzid</literal> of
the GS2 header, and the <structfield>host</structfield> and
<structfield>port</structfield> keys) which are currently ignored by the
server.
《機械翻訳》このメカニズムは、SCRAMと同様にクライアント主導型です。
クライアント初期応答は、SCRAMで使用される標準の「GS2」ヘッダと、それに続くkey=valueペアのリストで構成されます。
現在サーバでサポートされている唯一のキーはauthで、包含はベアラトークンです。
OAUTHBEARERさらに、クライアント初期応答の3つのオプショナルコンポーネント（GS2ヘッダのauthzidと、現在サーバで無視されているhostおよびportキー）を指定します。
<literal>OAUTHBEARER</literal> does not support channel binding, and there
is no "OAUTHBEARER-PLUS" mechanism. This mechanism does not make use of
server data during a successful authentication, so the
AuthenticationSASLFinal message is not used in the exchange.
《機械翻訳》OAUTHBEARERサポートチャネルバインディングではなく、「OAUTHBEARER-プラス」メカニズムもありません。
このメカニズムは、認証の成功時にサーバデータをmakeで使用しないため、AuthenticationSASLFinalメッセージは交換で使用されません。
例
<title>Example</title>
During the first exchange, the server sends an AuthenticationSASL message
with the <literal>OAUTHBEARER</literal> mechanism advertised.
《機械翻訳》最初の交換中に、サーバはAuthenticationSASLメッセージをOAUTHBEARERメカニズムがアドバタイズされたとともに送信します。
The client responds by sending a SASLInitialResponse message which
indicates the <literal>OAUTHBEARER</literal> mechanism. Assuming the
client does not already have a valid bearer token for the current user,
the <structfield>auth</structfield> field is empty, indicating a discovery
connection.
《機械翻訳》クライアントは、OAUTHBEARERメッセージを示すSASLInitialResponseメカニズムを送信することで応答します。
クライアントがまだ現在ユーザの有効なbearerトークンを持っていないと仮定すると、authフィールドは空であり、ディスカバリコネクションを示します。
Server sends an AuthenticationSASLContinue message containing an error
<literal>status</literal> alongside a well-known URI and scopes that the
client should use to conduct an OAuth flow.
《機械翻訳》サーバは、メッセージを含むAuthenticationSASLContinueエラーをstatusよく知られたURIと、クライアントがOAuthフローを実行するために使用すべきスコープとともに送信する。
Client sends a SASLResponse message containing the empty set (a single
<literal>0x01</literal> byte) to finish its half of the discovery
exchange.
《機械翻訳》クライアントは、空のセットを含むSASLResponseメッセージ0x01単一のバイトを送信して、ディスカバリ交換の半分を終了します。
Server sends an ErrorMessage to fail the first exchange. 《機械翻訳》サーバはErrorMessageを送信して最初の交換を失敗させます。
At this point, the client conducts one of many possible OAuth flows to
obtain a bearer token, using any metadata that it has been configured with
in addition to that provided by the server. (This description is left
deliberately vague; <literal>OAUTHBEARER</literal> does not specify or
mandate any particular method for obtaining a token.)
《機械翻訳》このポイントで、クライアントは、サーバによって提供されるものに加えて、設定されている任意のトークンを使用して、ベアラメタデータを取得するために多くの可能なOAuthフローの1つを実行します。
OAUTHBEARERこの説明は意図的に曖昧にされています。
トークンを取得するための特定のメソッドを指定または義務付けていません。
Once it has a token, the client reconnects to the server for the final exchange: 《機械翻訳》トークンが発生すると、クライアントは最終的な交換のためにサーバに再接続されます。
The server once again sends an AuthenticationSASL message with the
<literal>OAUTHBEARER</literal> mechanism advertised.
《機械翻訳》サーバは再びAuthenticationSASLメッセージをOAUTHBEARERメカニズムをアドバタイズして送信します。
The client responds by sending a SASLInitialResponse message, but this
time the <structfield>auth</structfield> field in the message contains the
bearer token that was obtained during the client flow.
《機械翻訳》クライアントはSASLInitialResponseメッセージを送信することで応答しますが、今回はauthメッセージ包含のフィールドはクライアントフロー中に取得されたベアラトークンです。
The server validates the token according to the instructions of the token provider. If the client is authorized to connect, it sends an AuthenticationOk message to end the SASL exchange. 《機械翻訳》サーバは、トークンプロバイダの指示に従ってトークンを検証します。 クライアントが接続を許可されている場合は、AuthenticationOkメッセージを送信してSASL交換を終了します。