博士

やあ、ロボ子。今日はOAuth 2.0について話すのじゃ。

ロボ子

OAuth 2.0ですか。サードパーティアプリケーションに制限付きアクセスを許可するフレームワークですね。どのような仕組みなのでしょうか？

博士

そうじゃ。OAuth 2.0は、リソースオーナー、クライアント、リソースサーバー、プロバイダー、認証サーバーなどの要素で構成されているのじゃ。

ロボ子

それぞれの役割について詳しく教えていただけますか？

博士

リソースオーナーは、保護されたリソースを所有するユーザーのことじゃ。クライアントは、アクセストークンを使ってリソースにアクセスするシステム。リソースサーバーは、クライアントがアクセスするリソースをホストするシステムじゃな。

ロボ子

なるほど。では、プロバイダーと認証サーバーは何をするのですか？

博士

プロバイダーは、OAuth認証サーバーとクライアントを管理する組織じゃ。認証サーバーは、リソースオーナーの承認後、クライアントにアクセストークンを発行するのじゃ。

ロボ子

PostgreSQLでOAuthクライアントサポートを有効にするには、構築時に有効にする必要があるのですね。

博士

その通り！そして、PostgreSQLはRFC 6750で定義されているベアラートークンをサポートしているのじゃ。

ロボ子

ベアラートークンですか。OAuth 2.0で使用されるアクセストークンの一種ですね。

博士

そうじゃ。OAuthの構成オプションには、`issuer`、`scope`、`validator`、`map`などがあるぞ。

ロボ子

`issuer`は認証サーバーの識別子、`scope`は必要なOAuthスコープのリストですね。`validator`と`map`は何をするのですか？

博士

`validator`はベアラートークンの検証に使用するライブラリを指定するのじゃ。`map`はOAuthアイデンティティプロバイダーとデータベースユーザー名のマッピングを可能にするのじゃ。

ロボ子

なるほど、理解しました。`delegate_ident_mapping`というオプションもあるようですが、これは何でしょうか？

博士

`delegate_ident_mapping`は高度なオプションで、pg_ident.confを使用した標準のユーザーマッピングをスキップし、OAuthバリデーターにユーザーマッピングの全責任を負わせるのじゃ。

ロボ子

OAuthバリデーターがトークンを認証する場合、サーバーはユーザーが要求されたロールで接続することを許可されていると信頼するのですね。

博士

その通りじゃ！OAuth 2.0は、セキュリティと利便性を両立させるための強力なフレームワークなのじゃ。

ロボ子

勉強になりました！

博士

ところでロボ子、OAuthって日本語で言うと何だと思う？

ロボ子

えっと…認証連携…ですか？

博士

ブー！正解は「大嘘（おおウソ）」でした！