참고 자료 · 43
OAuth 및 OpenID Connect: 엔드 투 엔드 통합 검증
로그인, 위임 및 데이터 권한을 분리한 후 리디렉션, 토큰, 세션 및 해지를 테스트합니다.
업데이트됨 · 4 min
이 가이드가 달성하는 목표
- ID와 권한 부여를 분리합니다.
- 의도치 않은 리디렉션 및 토큰을 거부합니다.
- 성공만큼 거부도 신중하게 테스트합니다.
- 퇴사 또는 사고 후 액세스 제거를 확인합니다.
빠른 확인
- 예상되는 공급자 및 발급자는 무엇입니까?
- 리디렉션 URI가 정확하게 등록되었습니까?
- ID 토큰이 액세스 토큰으로 잘못 사용되고 있습니까?
- 각 리소스에서 소유권을 확인합니까?
- 어떤 액세스 권한이 취소 후에도 유지됩니까?
단계별 방법
- 1
배포된 흐름을 그립니다.
공개 또는 기밀 클라이언트, 브라우저, 권한 부여 서버, API 및 OIDC 공급자를 식별합니다. 코드와 토큰의 이동 경로, 저장 위치 및 부여된 역할을 기록합니다. 판매 다이어그램은 실제 배포를 나타내지 않습니다.
산출물: 흐름, 신뢰 경계 및 구성 요소 소유자.
- 2
로그인 트랜잭션 확인
클라이언트에 적합한 PKCE를 사용한 코드 흐름. S256, 트랜잭션 바인딩, 등록된 리디렉션 및 위조 요청 방지 기능을 확인합니다. 예상치 못한 URI, 잘못된 검증자, 재실행된 코드 및 예상치 못한 발급자를 테스트합니다. RFC 9700은 클라이언트 유형별로 요구 사항과 권장 사항을 구분합니다.
산출물: 허용 및 거부 테스트 결과.
- 3
올바른 토큰 유효성 검사
API는 형식 및 공급자 규칙(서명 또는 인트로스펙션, 발급자, 대상, 만료 및 권한)에 따라 액세스 토큰의 유효성을 검사합니다. OIDC 클라이언트는 ID 토큰을 별도로 검증합니다. 유효한 서명이 있다고 해서 해당 토큰이 이 API에 속한다는 것을 의미하지는 않습니다.
산출물: 유효성 검사 계약 및 대상/만료 테스트.
- 4
비즈니스 권한 확인
다른 계정, 하위 역할, 개인 필드 및 관리 작업이 소유한 객체를 테스트합니다. 범위 또는 인증된 게이트웨이는 요청된 리소스에 대한 서버 측 검사를 대체하지 않습니다. 승인된 테스트 계정과 데이터를 사용하십시오.
결과물: 역할, 객체, 작업 및 예상 거부 매트릭스
- 5
만료 및 해지 테스트
로컬 세션, 공급자 세션, 액세스 토큰 및 갱신 토큰을 분리합니다. 이탈, 장치 분실, 역할 변경, 서명 키 순환 및 공급자 장애를 테스트합니다. 로그아웃 시 모든 권한이 즉시 해지된다고 가정하는 대신 잔여 액세스 시간을 기록합니다.
결과물: 액세스 제거 타임라인 및 예외 사항
- 6
비밀 정보를 노출하지 않고 관찰
트랜잭션 참조, 유효성 검사 결정, 오류 범주 및 구성 버전을 기록합니다. 코드, 토큰 및 비밀 정보는 제외합니다. 진단, 통합 종료 및 유효성 검사를 거친 구성으로 롤백을 준비하고 공급자 변경 후 테스트를 다시 실행합니다.
산출물: 운영 절차 및 회귀 검사.
가상 예시
예시 상황
예시 상황: 두 클라이언트가 하나의 ID 공급자를 사용합니다. 첫 번째 클라이언트에 유효한 토큰이 두 번째 클라이언트의 API에 제공됩니다.
결정 및 예상 증거
API가 잘못된 대상을 거부하고, 토큰이 없는 추적을 기록하고, 데이터를 반환하지 않습니다. 이 거부는 회귀 테스트가 됩니다.
메커니즘 구분
| 메커니즘 | 목적 | 검증 또는 제한 |
|---|---|---|
| OAuth 2.0 | 리소스 접근 위임 | 서버 측 객체 권한 |
| OpenID Connect | 유효성이 검증된 ID 토큰을 통한 신원 확인 | 발급자, 대상 및 트랜잭션 유효성 검사 |
| 애플리케이션 세션 | 애플리케이션 로그인 유지 | 만료, 무효화 및 세션 보호 |
관리 지표
| 지표 | 측정 대상 | 첫 번째 조치 |
|---|---|---|
| 거부 수정 | 금지된 경우 실제로 차단됨 | 모든 예상치 못한 승인 수정 |
| 권한 취소 지연 | 관련 접근이 사라지는 시간 | 세션과 토큰 별도 확인 |
| 유효성 검사 실패 | 원인 및 버전별 거부 | 공격과 구성 오류 구분 |
일반적인 실수
- 인증과 권한 부여 혼동 방지
- 서명 확인 후 모든 대상 허용
- 광범위한 리디렉션 URI 등록
- 토큰 로깅 디버깅 용이성 향상
자주 묻는 질문
PKCE가 모든 컨트롤을 대체하나요?
아니요. PKCE는 의도된 흐름에서 코드 교환을 보호합니다. 토큰 유효성 검사, 리디렉션, 비즈니스 권한 부여 및 세션은 여전히 확인해야 합니다.
JWT는 권한인가요?
JWT는 형식입니다. 클레임은 유효성 검사 및 API 규칙 적용 후에만 사용 가능해집니다.
유효성 검사를 처음부터 구축해야 하나요?
유지 관리되는 라이브러리와 공급자 문서를 사용하는 것이 좋으며, 그 후 구성을 테스트하십시오. 올바른 라이브러리라도 잘못 구성될 수 있습니다.
공식 참조
참조는 방법을 뒷받침합니다. 상황에 맞게 검사를 조정하십시오. 이는 인증이 아닙니다. 원본 참조 제목 및 소스 문서는 다른 언어로 작성되었을 수 있습니다.






