The validator must first ensure that the presented token is in fact a valid Bearer token for use in client authentication. The correct way to do this depends on the provider, but it generally involves either cryptographic operations to prove that the token was created by a trusted party (offline validation), or the presentation of the token to that trusted party so that it can perform validation for you (online validation). 《機械翻訳》バリデータは、まず保証に対して、提示されたトークンが実際にクライアント認証で使用するための有効な無記名トークンであることを示す必要があります。 これを行う正しい方法はプロバイダに依存しますが、通常は、トークンがトラステッドパーティ（オフラインバリデーション）によって作成されたことを証明するための暗号化操作、またはバリデーションを実行できるようにそのトラステッドパーティ（オンラインバリデーション）にトークンを提示することが含まれます。

Online validation, usually implemented via <ulink url="https://datatracker.ietf.org/doc/html/rfc7662">OAuth Token Introspection</ulink>, requires fewer steps of a validator module and allows central revocation of a token in the event that it is stolen or misissued. However, it does require the module to make at least one network call per authentication attempt (all of which must complete within the configured <xref linkend="guc-authentication-timeout"/>). Additionally, your provider may not provide introspection endpoints for use by external resource servers. 《機械翻訳》オンラインバリデーション（通常はOAuthトークンイントロスペクションを介して実装される）では、バリデータモジュールの手順が少なくて済み、盗難または誤発行されたイベントのトークンを一元的に失効させることができます。 ただし、モジュールは、認証の試行ごとに少なくとも1つのネットワーク呼び出しをmakeする必要があります（これらはすべて、構成されたauthentication_timeout内で完了する必要があります）。 また、プロバイダは、外部リソースサーバが使用するイントロスペクションエンドポイントを提供しない場合があります。

Offline validation is much more involved, typically requiring a validator to maintain a list of trusted signing keys for a provider and then check the token's cryptographic signature along with its contents. Implementations must follow the provider's instructions to the letter, including any verification of issuer ("where is this token from?"), audience ("who is this token for?"), and validity period ("when can this token be used?"). Since there is no communication between the module and the provider, tokens cannot be centrally revoked using this method; offline validator implementations may wish to place restrictions on the maximum length of a token's validity period. 《機械翻訳》オフラインバリデーションははるかに複雑であり、通常、バリデータはプロバイダのトラステッド署名キーのリストを維持し、チェックはトークンの暗号シグネチャとその内容を維持する必要があります。 実装は、発行者（「このトークンはどこから来たのか?」）、オーディエンス（「このトークンは誰のためのものか?」）、有効性ピリオド（「このトークンはいつ使用できるのか?」）の検証を含む、プロバイダの指示に従わなければなりません。 モジュールとプロバイダの間には通信がないため、このメソッドを使用してトークンを一元的に取り消すことはできません。 オフラインバリデータの実装では、トークンの有効性ピリオドの最大長さに制限を設けることができます。

If the token cannot be validated, the module should immediately fail. Further authentication/authorization is pointless if the bearer token wasn't issued by a trusted party. 《機械翻訳》トークンが検証できない場合、モジュールは直ちに失敗します。 無記名認証がトークン当事者によって発行されていない場合、それ以上のトラステッド/承認は無意味です。

Next the validator must ensure that the end user has given the client permission to access the server on their behalf. This generally involves checking the scopes that have been assigned to the token, to make sure that they cover database access for the current HBA parameters. 《機械翻訳》次に、バリデータは保証を実行する必要があります。 これは、エンドユーザがクライアントパーミッションをアクセスに提供したことを意味します。 サーバはに代わります。 これには通常、トークンにアサインされたスコープをチェックすることが含まれます。 makeは現在HBAパラメータのカバーデータベースアクセスを確認します。

The purpose of this step is to prevent an OAuth client from obtaining a token under false pretenses. If the validator requires all tokens to carry scopes that cover database access, the provider should then loudly prompt the user to grant that access during the flow. This gives them the opportunity to reject the request if the client isn't supposed to be using their credentials to connect to databases. 《機械翻訳》このステップの目的は、OAuthクライアントが偽のふりをしてトークンを取得するのを防ぐことです。 バリデータがすべてのトークンにカバーデータベースアクセスのスコープを運ぶことを要求する場合、プロバイダはフローの間にそのアクセスを許可するためにユーザをプロンプトする必要があります。 これにより、クライアントが資格情報を使用してデータベースに接続することになっていない場合に、リクエストを拒否する機会が与えられます。

While it is possible to establish client authorization without explicit scopes by using out-of-band knowledge of the deployed architecture, doing so removes the user from the loop, which prevents them from catching deployment mistakes and allows any such mistakes to be exploited silently. Access to the database must be tightly restricted to only trusted clients ^[17] if users are not prompted for additional scopes.

Even if authorization fails, a module may choose to continue to pull authentication information from the token for use in auditing and debugging. 《機械翻訳》認可が失敗した場合でも、モジュールは、監査およびデバッグで使用するために、認証からトークン情報をプルし続けることを選択できます。

Finally, the validator should determine a user identifier for the token, either by asking the provider for this information or by extracting it from the token itself, and return that identifier to the server (which will then make a final authorization decision using the HBA configuration). This identifier will be available within the session via <link linkend="functions-info-session-table"><function>system_user</function></link> and recorded in the server logs if <xref linkend="guc-log-connections"/> is enabled. 《機械翻訳》最後に、バリデータは、プロバイダにこの情報を要求するか、ユーザ識別子から情報を抽出することによって、トークンのトークン自分自身を決定し、その識別子をサーバに結果します（はHBA設定を使用して最終的な許可決定をmakeします）。 log_connectionsが有効になっている場合、この識別子はsystem_userを介してセッション内で使用可能になり、サーバログに記録されます。

Different providers may record a variety of different authentication information for an end user, typically referred to as <emphasis>claims</emphasis>. Providers usually document which of these claims are trustworthy enough to use for authorization decisions and which are not. (For instance, it would probably not be wise to use an end user's full name as the identifier for authentication, since many providers allow users to change their display names arbitrarily.) Ultimately, the choice of which claim (or combination of claims) to use comes down to the provider implementation and application requirements. 《機械翻訳》様々なプロバイダが、あるエンドユーザの様々な認証情報を要求する場合があります。 通常は要求と呼ばれます。 プロバイダは通常、これらの要求のうち、許可決定に使用できるほど信頼できるものと信頼できないものをレコードします（インスタンスの場合、エンドユーザのフルネームを認証の識別子として使用することは賢明ではありません。 多くのプロバイダでは、ユーザがディスプレイ名を任意に変更できます）。 結局のところ、どの要求（または要求の組合せ）を使用するかの選択は、プロバイダの実装とアプリケーションの要件に依存します。 ダウンドキュメント

Note that anonymous/pseudonymous login is possible as well, by enabling usermap delegation; see <xref linkend="oauth-validator-design-usermap-delegation"/>. 《機械翻訳》ノートの委任を有効にすることで、匿名/仮名のログインも可能です。 50.1.3を参照してください。 ユーザマップ

Modules should not write tokens, or pieces of tokens, into the server log. This is true even if the module considers the token invalid; an attacker who confuses a client into communicating with the wrong provider should not be able to retrieve that (otherwise valid) token from the disk. 《機械翻訳》モジュールは、サーバログにトークンまたはトークンの断片を書き込むべきではありません。 モジュールが真を無効と見なしたとしても、これはトークンです。 クライアントを混乱させて間違いプロバイダと通信させた攻撃者は、ディスクから（そうでなければ有効な）トークンを取得できないはずです。

Implementations that send tokens over the network (for example, to perform online token validation with a provider) must authenticate the peer and ensure that strong transport security is in use. 《機械翻訳》ネットワークを越えてトークンを送る実装（例に対して、プロバイダとオンライントークンバリデーションを行うために）は、強いトランスポートセキュリティが使われている同等なと保証を認証しなくてはなりません。

Modules may use the same <link linkend="error-message-reporting">logging facilities</link> as standard extensions; however, the rules for emitting log entries to the client are subtly different during the authentication phase of the connection. Generally speaking, modules should log verification problems at the <symbol>COMMERROR</symbol> level and return normally, instead of using <symbol>ERROR</symbol>/<symbol>FATAL</symbol> to unwind the stack, to avoid leaking information to unauthenticated clients. 《機械翻訳》モジュールは、標準拡張として同じロギングファシリティを使用する場合があります。 ただし、クライアントへのログエントリを発行するためのルールは、コネクションの認証フェーズ中に微妙に異なります。 一般的に、モジュールは通常、COMMERRORレベルと結果で問題を検証する必要があります。 代わりはERROR/FATALスタックを巻き戻すためにを使用して、認証されていないクライアントへの情報の漏洩を回避します。 ログ

Modules must remain interruptible by signals so that the server can correctly handle authentication timeouts and shutdown signals from <application>pg_ctl</application>. For example, blocking calls on sockets should generally be replaced with code that handles both socket events and interrupts without races (see <function>WaitLatchOrSocket()</function>, <function>WaitEventSetWait()</function>, et al), and long-running loops should periodically call <function>CHECK_FOR_INTERRUPTS()</function>. Failure to follow this guidance may result in unresponsive backend sessions. 《機械翻訳》モジュールは、サーバが正しくハンドル認証タイムアウトとpg_ctlからのシャットダウンシグナルを処理できるように、シグナルによる割り込みが可能でなければなりません。 例では、ソケット上のブロッキング呼び出しは、一般的にソケットイベントと競合のない割り込みの両方を処理するコードに置き換えるべきです。 WaitLatchOrSocket()、WaitEventSetWait()、などを参照してください。 また、長時間実行されるループは定期的に呼び出しする必要があります。 このガイダンスに従わないと、バックエンドセッションが応答しなくなる可能性があります。 CHECK_FOR_INTERRUPTS()

The breadth of testing an OAuth system is well beyond the scope of this documentation, but at minimum, negative testing should be considered mandatory. It's trivial to design a module that lets authorized users in; the whole point of the system is to keep unauthorized users out. 《機械翻訳》OAuthシステムのテストの幅は、このスコープの文書をはるかに超えていますが、少なくともネガティブテストは必須であると考えるべきです。 デザインにとって、許可されたユーザを許可するモジュールは簡単です。 システムのポイント全体は、許可されていないユーザを締め出すことです。

Validator implementations should document the contents and format of the authenticated ID that is reported to the server for each end user, since DBAs may need to use this information to construct pg_ident maps. (For instance, is it an email address? an organizational ID number? a UUID?) They should also document whether or not it is safe to use the module in <symbol>delegate_ident_mapping=1</symbol> mode, and what additional configuration is required in order to do so. 《機械翻訳》DBAはpg_identマップをバリデータするためにこの情報を使用する必要があるかもしれないので、ドキュメント実装は認証されたIDの内容とフォーマットをサーバする必要があります。 (インスタンスの場合、メールアドレスですか?組織ID番号ですか?UUIDですか?また、モジュールをdelegate_ident_mapping=1モードで使用するのがセーフかどうか、そしてそうするためにオーダーで必要な追加の設定は何かをドキュメントする必要があります。 エンドユーザコンストラクト