[PostgreSQL 18][OAuth role map 오류] authn_id와 DB role이 다를 때 pg_ident.conf를 확인하는 순서

IT 리서치 노트

[PostgreSQL 18][OAuth role map 오류] authn_id와 DB role이 다를 때 pg_ident.conf를 확인하는 순서

PostgreSQL 18 OAuth에서 provider 승인은 끝났는데 원하는 DB role로 접속하지 못하면 token보다 authn_id와 pg_ident.conf를 먼저 봐야 한다. 2026년 9월 5일 KST 기준 공식 문서상 map을 쓰지 않으면 authn_id가 요청 role과 정확히 같아야 한다. 이 글은 식별자 형식, HBA map 이름, 파일 파싱, reload, current_user 순으로 오류를 좁힌다.

목차

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

1. 개요

validator가 반환한 authn_id가 이메일이고 DB role이 analyst라면 map 없이는 접속할 수 없다. pg_hba.conf의 map 이름과 pg_ident.conf의 외부 식별자·role 행을 연결하고, system view의 error를 확인한 뒤 설정을 reload한다.

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

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

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

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

특히 pg_ident_file_mappings는 디스크의 현재 파일을 보여 주므로 error가 없다는 사실만으로 서버에 새 규칙이 반영됐다고 단정할 수 없다.

운영 기록에는 첫 실패 단계와 기대값, 실제값, 설정 반영 시각만 남긴다. 이렇게 하면 인증 제공자, 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 버전을 함께 기록해 다음 장애에서 비교 기준으로 쓴다.

# pg_hba.conf
hostssl appdb all 10.0.0.0/8 oauth issuer=https://id.example.com scope="db.login" validator=example_validator map=oauthmap

# pg_ident.conf
oauthmap user-1234 analyst

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

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

첫 화면에서는 map을 생략했을 때의 기본 규칙을 확인한다. 강조된 문장과 필드 이름을 실제 설정값과 대조한다.

map이 없으면 validator의 authn_id와 요청한 DB role이 정확히 같아야 한다.

이메일이나 UUID를 반환하는 provider라면 별도 usermap이 필요한지 먼저 판단한다. 다음 단계에서도 같은 식별자와 role이 이어지는지 확인한다.

두 번째 화면은 pg_ident.conf의 세 필드 형식이다. 강조된 문장과 필드 이름을 실제 설정값과 대조한다.

map 이름, 외부 식별자, PostgreSQL role을 한 줄에 연결한다.

여러 DB role을 허용하면 행별 허용 관계로 읽어야 하며 동등 관계로 오해하면 안 된다. 다음 단계에서도 같은 식별자와 role이 이어지는지 확인한다.

세 번째 화면에서는 파일을 눈으로만 보지 않고 system view의 error 열을 확인한다. 강조된 문장과 필드 이름을 실제 설정값과 대조한다.

pg_ident_file_mappings는 현재 파일 내용의 파싱 결과를 줄 단위로 보여 준다.

현재 파일 내용과 마지막 reload된 상태는 다를 수 있으므로 reload 성공도 별도로 확인한다. 다음 단계에서도 같은 식별자와 role이 이어지는지 확인한다.

role map 실패는 받은 식별자, 요청 role, map 이름, reload 순서로 좁힌다. 강조된 문장과 필드 이름을 실제 설정값과 대조한다.

OAuth authn_id가 DB role로 승인되는 흐름이다.

첫 불일치 지점만 고치고 나머지 설정은 유지한다. 다음 단계에서도 같은 식별자와 role이 이어지는지 확인한다.

마지막 화면은 secret 없이 실행할 수 있는 파싱·reload·접속 확인 명령이다. 강조된 문장과 필드 이름을 실제 설정값과 대조한다.

pg_ident_file_mappings의 error와 current_user를 차례로 확인한다.

실패 로그에는 token 대신 authn_id 형식과 map 결과만 남긴다. 다음 단계에서도 같은 식별자와 role이 이어지는지 확인한다.

5. 주의사항과 리스크

all을 database username에 사용하면 한 외부 사용자가 모든 기존 role로 로그인할 수 있다. 정규식 map도 예상보다 넓게 일치할 수 있으므로 허용·거부 사례를 같이 테스트한다. 이메일은 변경될 수 있어 provider의 안정적인 subject가 더 적합할 수 있다.

6. 결론

role map 장애는 authn_id의 실제 값과 요청 role을 먼저 고정하면 짧게 풀린다. validator 반환 구조는 validate_cb 검증 순서, 인증 방식 선택은 OAuth와 SCRAM 비교에서 함께 확인할 수 있다.

7. 참고 링크

1. https://www.postgresql.org/docs/18/auth-oauth.html
2. https://www.postgresql.org/docs/18/auth-username-maps.html
3. https://www.postgresql.org/docs/18/view-pg-ident-file-mappings.html
4. https://www.postgresql.org/docs/18/view-pg-hba-file-rules.html
5. https://www.postgresql.org/docs/18/oauth-validator-callbacks.html