他のバージョンの文書 18 | 17 | 16 | 15 | 14 | 13 | 12 | 11 | 10 | 9.6 | 9.5 | 9.4 | 9.3 | 9.2 | 9.1 | 9.0 | 8.4 | 8.3 | 8.2 | 8.1 | 8.0 | 7.4 | 7.3 | 7.2

20.15. OAuth認可/認証 #

OAuth 2.0は、RFC 6749で定義されている業界標準のフレームワークであり、サードパーティのアプリケーションが保護されたリソースへの限定されたアクセスを取得できるようにします。 PostgreSQLを構築する際、OAuthクライアントサポートを有効にする必要があります。詳細については第17章を参照してください。

この文書では、OAuthエコシステムについて議論する際に次の用語を使用しています。

リソース所有者(またはエンドユーザ)

保護されたリソースを所有し、アクセスを与えることができるユーザまたはシステム。 この文書は、リソース所有者が個人の場合にもエンドユーザという用語を使用します。 psqlを使用して、OAuthを使用してデータベースに接続する場合、ユーザはリソース所有者/エンドユーザになります。

クライアント

アクセストークンを使用して保護されたリソースにアクセスするシステム。 psqlなどのlibpqを使用するアプリケーションは、PostgreSQLクラスタに接続するときのOAuthクライアントです。

リソースサーバ

クライアントによってアクセスされる保護されたリソースをホスティングするシステム。 接続されるPostgreSQLクラスタはリソースサーバです。

プロバイダ

特定のアプリケーションのためにOAuth認証サーバおよびクライアントを開発および/または管理する組織、プロダクトベンダ、その他のエンティティ。 典型的には、プロバイダが異なれば、OAuthシステムに対して選択する実装の詳細も異なります。 あるプロバイダのクライアントが別のプロバイダのサーバに対してアクセスできる保証は通常ありません。

この「プロバイダ」という用語の使用は標準的ではありませんが、一般的に広く使用されているようです。 (OpenIDの類似用語である「IDプロバイダ」と混同しないでください。 PostgreSQLでのOAuthの実装はOpenID Connect/OIDCとの相互運用と互換性を意図していますが、自分自身はOIDCクライアントではないため、使用する必要はありません。)

認可サーバ

認証されたリソース所有者が承認した後に、クライアントからアクセストークンのリクエストを受信し、アクセストークンをクライアントに発行するシステム。 PostgreSQLは認可サーバを提供しません。これはOAuthプロバイダの責任です。

発行者

OAuthクライアントのための信頼された「名前空間」で、https:// URLの形で印字される認可サーバの識別子。 発行者識別子により、それらが別々の発行者を保持する限り、単一の認可サーバが相互に信用していないエンティティのクライアントと話すことを可能にします。

注記

小規模な導入では、「プロバイダ」、「認可サーバ」、および「発行者」の間に意味のある区別がない場合があります。 ただし、より複雑な設定では、1対多(または多対多)のリレーションが存在する場合があります。 プロバイダは、複数の発行者識別子を別々のテナントに貸し出し、テナントがクライアントと対話するために、場合によっては異なる機能の組み合わせをサポートする複数の認証サーバを提供することがあります。

PostgreSQLは、RFC 6750で定義されているベアラ(bearer)トークンをサポートします。 これは、OAuth 2.0で使用されるアクセストークンの型です。 トークンは不透明文字列です。 アクセストークンのフォーマットは実装固有であり、各認可サーバによって選択されます。

OAuth用に、次の設定オプションがサポートされています。

issuer

ディスカバリー文書によって定義された認可サーバの正確な発行者識別子であるか、またはそのディスカバリー文書を直接指す既知のURIであるHTTPS URLです。 このパラメータは必須です。

OAuthクライアントがサーバに接続する際に、その発行者識別子を用いてディスカバリー文書のURLを構築します。 デフォルトでは、このURLはOpenID Connect Discoveryの規約であるパス/.well-known/OpenID-configuration発行者識別子の末尾に付加されます。 あるいは、issuer/.well-known/パスセグメントを含んでいる場合、そのURLがそのままクライアントに提供されます。

警告

libpqのOAuthクライアントは、サーバ発行者の設定が、正確にディスカバリー文書中で提供された発行者識別子と一致する必要があり、そしてそれはクライアントのoauth_issuer設定と一致しなければなりません。 大文字小文字やフォーマットの変更は許可されません。

scope

サーバがクライアントを認可し、ユーザを認証するのに必要な空白で区切られたOAuthスコープです。 認証サーバとOAuth検証モジュールによって適切な値が決まります(検証器の詳細は第50章を参照)。 このパラメータは必須です。

validator

ベアラトークンの検証に使用するライブラリ。 指定する場合、名前はoauth_validator_librariesに列挙されているライブラリの1つと正確にマッチする必要があります。 このパラメータは、oauth_validator_librariesが複数のライブラリを含んでいる場合を除き、オプションです。複数のライブラリが含まれていれば必須です。

map

OAuthアイデンティティプロバイダとデータベースユーザ名の間のマッピングを可能にします。 詳細は、20.2を参照してください。 マップが指定されていない場合、(OAuth検証器によって決定される)トークンに関連付けられたユーザ名は、要求されているロール名と正確にマッチする必要があります。 このパラメータはオプションです。

delegate_ident_mapping

一般的な使用を目的としない高度なオプション。

1に設定すると、pg_ident.confによる標準ユーザマッピングはスキップされ、OAuth検証器はデータベースロールに対するマッピングエンドユーザIDに対して完全な責任を負います。 検証器がトークンを認可すると、サーバはユーザが要求されたロールの下で接続できることを信頼し、ユーザの認証ステータスに関係なくコネクションを続行できます。

このパラメータはmapと互換性がありません。

警告

delegate_ident_mappingは認証システムのデザインに追加の柔軟性を提供しますが、提供されたトークンがすべての検証器に必要な標準チェックに加えて、十分なエンドユーザ権限を持っているかどうかを判断するOAuth検証器の注意深い実装も必要です。 注意して使用してください。