[PostgreSQL 18][OAuth 보안] delegate_ident_mapping=1을 쓰기 전에 scope와 요청 role을 검증해야 하는 이유

IT 리서치 노트

[PostgreSQL 18][OAuth 보안] delegate_ident_mapping=1을 쓰기 전에 scope와 요청 role을 검증해야 하는 이유

PostgreSQL 18의 delegate_ident_mapping=1은 pg_ident.conf 관리를 줄여 주는 단축 옵션이 아니다. 2026년 9월 5일 KST 기준 공식 문서는 이 옵션을 일반 용도가 아닌 고급 설정으로 분류하며, validator가 요청 role 권한까지 전부 책임져야 한다고 경고한다. 이 글은 표준 usermap과 delegate 모드를 비교하고 배포 전에 반드시 거부해야 할 사례를 정리한다.

목차

1. 개요
2. 어디서 실제로 막히는가
3. 실무에서 적용하는 순서
4. 공식 문서와 예시 화면으로 확인하기
5. 주의사항과 리스크
6. 결론
7. 참고 링크

1. 개요

특별히 검증된 중앙 권한 모델이 없다면 map을 사용하는 표준 흐름이 기본값이다. delegate 모드에서는 PostgreSQL이 authn_id와 role 관계를 검사하지 않으므로 validator가 token의 scope, tenant, group과 요청 role을 직접 대조해야 한다.

2. 어디서 실제로 막히는가

진단할 때는 토큰 발급 성공과 DB 접속 성공을 같은 사건으로 취급하지 않는다. provider 승인 뒤에도 validator의 반환값, 인증 식별자, 요청 role, usermap이 차례로 남아 있다. 로그에는 토큰 원문 대신 단계와 판정만 남겨야 앞단 보안 문제를 만들지 않고 실패 위치를 좁힐 수 있다.

• token 자체를 로그에 남기지 않는다.
• authn_id와 요청 role을 별도 필드로 기록한다.
• 설정 파일의 현재 내용과 실제 reload 여부를 나눠 확인한다.

증상도 층별로 다르다. device 승인 전에 멈추면 discovery와 client 흐름을 보고, 승인 직후 거부되면 validator의 issuer·audience·만료 판정을 본다. validator가 승인했지만 접속이 끝나지 않으면 authn_id와 요청 role, usermap을 비교한다. 이 구분 없이 모든 설정을 동시에 바꾸면 원래 실패 지점이 사라져 재현과 rollback이 어려워진다.

가장 위험한 구현은 token이 유효하면 요청 role과 무관하게 authorized=true를 반환하는 것이다. 이 경우 낮은 권한 token으로 더 높은 DB role을 요청하는 경로가 열릴 수 있다.

운영 기록에는 첫 실패 단계와 기대값, 실제값, 설정 반영 시각만 남긴다. 이렇게 하면 인증 제공자, DB 설정, validator 구현 중 어느 담당자가 확인해야 하는지 바로 나뉜다.

3. 실무에서 적용하는 순서

테스트는 허용 사례 하나보다 거부 사례를 먼저 설계한다. 만료 토큰, 잘못된 audience, 부족한 scope, 다른 tenant, 허용되지 않은 role을 각각 넣고 첫 실패 단계가 기대한 위치인지 확인한다. 마지막에는 제한된 테스트 role로 접속해 SELECT current_user;를 실행한다.

1. 설정 파일 파싱 오류를 system view로 확인한다.
2. validator가 token 검증을 완료했는지 확인한다.
3. authn_id와 요청 role의 매핑 결과를 확인한다.
4. 허용·거부 케이스를 모두 실행한다.
5. 성공 접속에서 current_user를 확인한다.

배포 전에는 테스트 전용 issuer 또는 client와 권한이 제한된 DB role을 사용한다. 각 요청마다 discovery 완료, token 판정, identity 추출, role 승인, 접속 완료를 서로 다른 상태로 남긴다. 실패하면 첫 번째 비정상 상태만 수정하고 같은 케이스를 다시 실행한다. 성공 뒤에는 설정 reload 시각과 validator 버전을 함께 기록해 다음 장애에서 비교 기준으로 쓴다.

allowed_roles = roles_from_verified_claims(token)
if requested_role not in allowed_roles:
    authorized = false
else:
    authorized = true
# token 원문은 기록하지 않는다.

각 단계가 끝날 때 성공 신호를 하나씩 남긴다. 설정 view의 error가 비었는지, validator가 정상 판정을 반환했는지, 최종 role이 기대와 같은지 확인하고 다음 단계로 이동한다.

4. 공식 문서와 예시 화면으로 확인하기

첫 화면에서는 이 옵션이 일반적인 설정이 아니라는 경고부터 확인한다. 강조된 문장과 필드 이름을 실제 설정값과 대조한다.

delegate_ident_mapping은 pg_ident 검사를 건너뛰는 고급 옵션이다.

단순히 map 파일을 줄이는 편의 옵션으로 사용하면 안 된다. 다음 단계에서도 같은 식별자와 role이 이어지는지 확인한다.

두 번째 화면은 책임 이동을 보여 준다. validator가 token 검증뿐 아니라 요청 role 승인까지 전부 맡는다. 강조된 문장과 필드 이름을 실제 설정값과 대조한다.

Usermap delegation은 validator를 접속 권한 판정의 단일 실패 지점으로 만든다.

구현 문서와 negative test가 없는 모듈에서는 사용하지 않는 편이 안전하다. 다음 단계에서도 같은 식별자와 role이 이어지는지 확인한다.

세 번째 화면에서는 delegate 모드에서 서버가 authn_id를 검사하지 않는다는 점을 본다. 강조된 문장과 필드 이름을 실제 설정값과 대조한다.

delegate 모드에서는 authorized=true가 요청 role 접속을 사실상 승인한다.

validator가 token scope와 요청 role의 포함 관계를 직접 검사해야 한다. 다음 단계에서도 같은 식별자와 role이 이어지는지 확인한다.

표준 map과 delegate 모드는 마지막 권한 판정 주체가 다르다. 강조된 문장과 필드 이름을 실제 설정값과 대조한다.

pg_ident map과 delegate_ident_mapping의 책임 비교다.

특별한 중앙 권한 모델이 없다면 표준 map을 기본값으로 둔다. 다음 단계에서도 같은 식별자와 role이 이어지는지 확인한다.

마지막 화면은 배포 전에 반드시 실패해야 하는 요청을 고정한다. 강조된 문장과 필드 이름을 실제 설정값과 대조한다.

delegate 모드의 최소 negative test 목록이다.

하나라도 통과하면 배포를 중단하고 role 판정 코드를 수정한다. 다음 단계에서도 같은 식별자와 role이 이어지는지 확인한다.

5. 주의사항과 리스크

delegate_ident_mapping은 map 옵션과 함께 사용할 수 없다. device authorization처럼 public client를 전제로 한 흐름은 validator와 server가 모두 신뢰된 동일 주체라는 가정을 충족하지 않을 수 있다. 익명 또는 가명 접속도 가능해지므로 감사 요구와 충돌하는지 확인한다.

6. 결론

delegate 모드의 핵심은 편의가 아니라 권한 책임의 완전한 이동이다. 먼저 pg_ident role map 점검 순서로 표준 구성을 검토하고, 구현 단계에서는 validate_cb 반환값과 검증 순서를 기준으로 negative test를 준비한다.

7. 참고 링크

1. https://www.postgresql.org/docs/18/auth-oauth.html
2. https://www.postgresql.org/docs/18/oauth-validator-design.html
3. https://www.postgresql.org/docs/18/oauth-validator-callbacks.html