-
[PostgreSQL 18][OAuth Validator] validate_cb에서 token·role·authn_id를 어떤 순서로 검사해야 하나기타개발지식/풀스택개발 2026. 9. 5. 20:07
IT 리서치 노트
[PostgreSQL 18][OAuth Validator] validate_cb에서 token·role·authn_id를 어떤 순서로 검사해야 하나
PostgreSQL 18 OAuth validator를 구현할 때 가장 위험한 오해는 bearer token이 문법상 정상이라는 이유로 검증도 끝났다고 보는 것이다. 2026년 9월 5일 KST 기준 공식 문서상 PostgreSQL은 token의 문법만 확인한 뒤 원문과 요청 role을 validate_cb에 넘긴다. 이 글은 callback 반환값, authorized, authn_id를 분리하고 안전한 검증 순서를 정리한다.
1. 개요
validator는 issuer, audience, 만료, scope를 검증한 뒤 안정적인 사용자 식별자를 authn_id로 돌려줘야 한다. callback의 false는 내부 오류이고, 정상 거부는 true를 반환하면서 authorized=false로 표시한다.
2. 어디서 실제로 막히는가
진단할 때는 토큰 발급 성공과 DB 접속 성공을 같은 사건으로 취급하지 않는다. provider 승인 뒤에도 validator의 반환값, 인증 식별자, 요청 role, usermap이 차례로 남아 있다. 로그에는 토큰 원문 대신 단계와 판정만 남겨야 앞단 보안 문제를 만들지 않고 실패 위치를 좁힐 수 있다.
- token 자체를 로그에 남기지 않는다.
- authn_id와 요청 role을 별도 필드로 기록한다.
- 설정 파일의 현재 내용과 실제 reload 여부를 나눠 확인한다.
증상도 층별로 다르다. device 승인 전에 멈추면 discovery와 client 흐름을 보고, 승인 직후 거부되면 validator의 issuer·audience·만료 판정을 본다. validator가 승인했지만 접속이 끝나지 않으면 authn_id와 요청 role, usermap을 비교한다. 이 구분 없이 모든 설정을 동시에 바꾸면 원래 실패 지점이 사라져 재현과 rollback이 어려워진다.
운영 기록에는 첫 실패 단계와 기대값, 실제값, 설정 반영 시각만 남긴다. 이렇게 하면 인증 제공자, DB 설정, validator 구현 중 어느 담당자가 확인해야 하는지 바로 나뉜다.
3. 실무에서 적용하는 순서
테스트는 허용 사례 하나보다 거부 사례를 먼저 설계한다. 만료 토큰, 잘못된 audience, 부족한 scope, 다른 tenant, 허용되지 않은 role을 각각 넣고 첫 실패 단계가 기대한 위치인지 확인한다. 마지막에는 제한된 테스트 role로 접속해
SELECT current_user;를 실행한다.- 설정 파일 파싱 오류를 system view로 확인한다.
- validator가 token 검증을 완료했는지 확인한다.
- authn_id와 요청 role의 매핑 결과를 확인한다.
- 허용·거부 케이스를 모두 실행한다.
- 성공 접속에서 current_user를 확인한다.
배포 전에는 테스트 전용 issuer 또는 client와 권한이 제한된 DB role을 사용한다. 각 요청마다 discovery 완료, token 판정, identity 추출, role 승인, 접속 완료를 서로 다른 상태로 남긴다. 실패하면 첫 번째 비정상 상태만 수정하고 같은 케이스를 다시 실행한다. 성공 뒤에는 설정 reload 시각과 validator 버전을 함께 기록해 다음 장애에서 비교 기준으로 쓴다.
callback_ok=true authorized=false reason=audience_mismatch token_logged=false각 단계가 끝날 때 성공 신호를 하나씩 남긴다. 설정 view의 error가 비었는지, validator가 정상 판정을 반환했는지, 최종 role이 기대와 같은지 확인하고 다음 단계로 이동한다.
4. 공식 문서와 예시 화면으로 확인하기
첫 화면에서는 validator의 책임을 token 검증, 사용자 식별, 권한 판정으로 나눠 본다. 강조된 문장과 필드 이름을 실제 설정값과 대조한다.
서명만 맞는지 보는 것으로 끝내지 말고 issuer, audience, expiry, scope를 함께 검사한다. 다음 단계에서도 같은 식별자와 role이 이어지는지 확인한다.
두 번째 화면은 모듈 초기화 계약이다. 필수 callback과 선택 callback을 구분한다. 강조된 문장과 필드 이름을 실제 설정값과 대조한다.
startup과 shutdown은 선택이지만 validate_cb는 반드시 제공해야 한다. 다음 단계에서도 같은 식별자와 role이 이어지는지 확인한다.
세 번째 화면에서는 반환값 세 가지를 분리한다. callback 실행 성공, authorized 판정, authn_id는 같은 값이 아니다. 강조된 문장과 필드 이름을 실제 설정값과 대조한다.
내부 오류는 false, 정상적인 거부는 true와 authorized=false로 구분한다. 다음 단계에서도 같은 식별자와 role이 이어지는지 확인한다.
반환 조합을 표로 고정하면 장애와 정상 거부를 모니터링에서 나눌 수 있다. 강조된 문장과 필드 이름을 실제 설정값과 대조한다.
거부율과 validator 내부 오류율을 별도 지표로 두는 것이 핵심이다. 다음 단계에서도 같은 식별자와 role이 이어지는지 확인한다.
마지막 화면은 구현 순서를 안전한 의사 코드로 고정한다. 실제 provider SDK 호출은 환경에 맞게 바꿔야 한다. 강조된 문장과 필드 이름을 실제 설정값과 대조한다.
negative test를 붙여 각 조건이 빠졌을 때 반드시 거부되는지 확인한다. 다음 단계에서도 같은 식별자와 role이 이어지는지 확인한다.
5. 주의사항과 리스크
PostgreSQL 18은 기본 validator 구현을 제공하지 않는다. 직접 구현하거나 별도 모듈을 검토해야 하며, 잘못된 구현은 인증이 없는 것보다 더 위험할 수 있다. blocking network call과 자원 해제도 backend 안정성에 영향을 준다.
6. 결론
validate_cb는 token 검증, 사용자 식별, 권한 판정을 한 함수 안에서 섞지 말고 단계별로 실패시켜야 한다. 전체 도입 구성은 PostgreSQL 18 OAuth 준비 항목, issuer 문제는 psql OAuth 실패 점검 순서에서 이어서 볼 수 있다.
7. 참고 링크
'기타개발지식 > 풀스택개발' 카테고리의 다른 글
