検証器は、まず、提示されたトークンが実際にクライアント認証で使用するための有効なベアラトークンであることを確認する必要があります。 これを行う正しい方法はプロバイダに依存しますが、通常は、トークンが信頼できる組織によって作成されたことを証明するための暗号処理（オフラインバリデーション）、またはバリデーションを実行できるようにその信頼できる組織にトークンを提示する（オンラインバリデーション）ことが含まれます。

オンライン検証（通常はOAuthトークンイントロスペクションを介して実装される）では、検証器モジュールの手順が少なくて済み、盗難または誤発行されたイベントのトークンを一元的に失効させることができます。 ただし、モジュールは、認証の試行ごとに少なくとも1つのネットワーク呼び出しを行う必要があります（これらはすべて、設定されたauthentication_timeout内で完了する必要があります）。 また、プロバイダは、外部リソースサーバが使用するイントロスペクションエンドポイントを提供しない場合があります。

オフライン検証ははるかに複雑であり、通常検証器はプロバイダのトラステッド署名キーのリストを維持し、チェックはトークンの暗号署名とその内容を維持する必要があります。 実装は、発行者（「このトークンはどこから来たのか?」）、オーディエンス（「このトークンは誰のためのものか?」）、有効性ピリオド（「このトークンはいつ使用できるのか?」）の検証を含む、プロバイダの指示に従わなければなりません。 モジュールとプロバイダの間には通信がないため、このメソッドを使用してトークンを一元的に取り消すことはできません。 オフライン検証器の実装では、トークンの有効性ピリオドの最大長さに制限を設けることができます。

トークンが検証できない場合、モジュールは直ちに失敗します。 ベアラトークンが信頼できる組織によって発行されていない場合、それ以上の認証／認可は無意味です。

次に検証器は、エンドユーザが、彼らに代わってサーバによるクライアントアクセスの許可を与えていることを確認しなければなりません。 これには通常、現在のHBAパラメータによるデータベースアクセスをカバーしていることを確認するために、トークンにアサインされたスコープをチェックすることが含まれます。

このステップの目的は、OAuthクライアントが虚偽の理由でトークンを取得するのを防ぐことです。 検証器がすべてのトークンにデータベースアクセスを可能にする内容を伴うことを要求する場合、処理中にプロバイダはユーザにアクセス許可を明示的に求める必要があります。 これにより、クライアントが資格情報を使用してデータベースに接続することになっていない場合に、リクエストを拒否する機会が与えられます。

デプロイされたアーキテクチャに関する外部から得た知識を用いることで、明示的なスコープを用いずにクライアント認可を確立することも可能ですが、そうするとユーザを処理の中から排除し、設定の誤りに気が付かなくなることになり、その誤りが気が付かないうちに悪用されることになります。 もしユーザが追加のスコープの入力を求められない場合は、データベースへのアクセスは信頼できるユーザ ^[17] にのみしっかりと制限されなければなりません。

認可が失敗した場合でも、モジュールは、監査およびデバッグで使用するために、トークンから認証情報を引き続き取得し続けることを選択できます。

最後に、検証器は、プロバイダにこの情報を要求するか、トークン自身からこの情報を抽出することによって、識別子をサーバに返します（サーバはHBA設定を使用して最終的な認可を決定します）。 log_connectionsが有効になっている場合、この識別子はsystem_userを介してセッション内で使用可能になり、サーバログに記録されます。

様々なプロバイダが、あるエンドユーザの様々な認証情報を記録する場合があります、通常は要求（claims）と呼ばれます。 プロバイダは通常、これらの要求のうち、許可決定に使用できるほど信頼できるものと信頼できないものを記録します。 （たとえば、多くのプロバイダでは、ユーザがディスプレイ名を任意に変更できるので、エンドユーザのフルネームを認証の識別子として使用することは賢明ではありません。） 結局のところ、どの要求（または要求の組合せ）を使用するかの選択は、プロバイダの実装とアプリケーションの要件に依存します。

ユーザマップ委任を有効にすることで、匿名/仮名のログインも可能であることに注意してください。50.1.3を参照してください。

モジュールは、サーバログにトークンまたはトークンの断片を書き込むべきではありません。 モジュールがトークンを無効だと見なしたとしても、これは当てはまります。クライアントを混乱させて間違ったプロバイダと通信させようとする攻撃者が、ディスクから（そうでなければ有効な）トークンを取得できるべきではありません。

（例えば、プロバイダとオンライントークンバリデーションを行うために）ネットワークを介してトークンを送信する実装は、ピアを認証し、強力なトランスポートセキュリティが使用されていることを確認する必要があります。

モジュールは、標準の拡張機能と同様に、同じロギングファシリティを使用できます。ただし、コネクションの認証フェーズ中にクライアントへログエントリを出力する際のルールは、微妙に異なります。 一般的に、認証されていないクライアントへの情報の漏洩を回避するために、ERROR/FATALを使用してスタックを巻き戻すのではなく、検証上の問題をCOMMERRORレベルでログに記録し、正常に終了する方が適切です。

モジュールは、サーバが正しく認証タイムアウトとpg_ctlからのシャットダウンシグナルを処理できるように、シグナルによる割り込みが可能でなければなりません。 たとえば、ソケット上のブロッキング呼び出しは、一般的にソケットイベントと割り込みの両方を競合せずに処理するコードに置き換えるべきで（WaitLatchOrSocket()、WaitEventSetWait()、などを参照してください）、長時間実行されるループはCHECK_FOR_INTERRUPTS()定期的に呼び出しする必要があります。 このガイダンスに従わないと、バックエンドセッションが応答しなくなる可能性があります。

OAuthシステムのテストの幅は、この文書のスコープをはるかに超えていますが、少なくともネガティブテストは必須であると考えるべきです。 許可されたユーザをログインさせるモジュールを設計するのは簡単です。 システムの全体的なポイントは、許可されていないユーザを締め出すことです。

DBAがpg_identマップを作成するためにこの情報を使用する必要があるかもしれないので、実装はサーバに報告される各ユーザの認証されたIDの内容と形式を文書化する必要があります。 （たとえば、それはメールアドレスか？組織ID番号か？UUIDか？） また、モジュールをdelegate_ident_mapping=1モードで使用するのが安全かどうか、そしてそうするための追加の設定は何かも文書化するのが良いでしょう。