참고 자료 · 43

OAuth 및 OpenID Connect: 엔드 투 엔드 통합 검증

로그인, 위임 및 데이터 권한을 분리한 후 리디렉션, 토큰, 세션 및 해지를 테스트합니다.

업데이트됨 · 4 min

이 가이드가 달성하는 목표

  • ID와 권한 부여를 분리합니다.
  • 의도치 않은 리디렉션 및 토큰을 거부합니다.
  • 성공만큼 거부도 신중하게 테스트합니다.
  • 퇴사 또는 사고 후 액세스 제거를 확인합니다.

빠른 확인

  • 예상되는 공급자 및 발급자는 무엇입니까?
  • 리디렉션 URI가 정확하게 등록되었습니까?
  • ID 토큰이 액세스 토큰으로 잘못 사용되고 있습니까?
  • 각 리소스에서 소유권을 확인합니까?
  • 어떤 액세스 권한이 취소 후에도 유지됩니까?

단계별 방법

  1. 1

    배포된 흐름을 그립니다.

    공개 또는 기밀 클라이언트, 브라우저, 권한 부여 서버, API 및 OIDC 공급자를 식별합니다. 코드와 토큰의 이동 경로, 저장 위치 및 부여된 역할을 기록합니다. 판매 다이어그램은 실제 배포를 나타내지 않습니다.

    산출물: 흐름, 신뢰 경계 및 구성 요소 소유자.

  2. 2

    로그인 트랜잭션 확인

    클라이언트에 적합한 PKCE를 사용한 코드 흐름. S256, 트랜잭션 바인딩, 등록된 리디렉션 및 위조 요청 방지 기능을 확인합니다. 예상치 못한 URI, 잘못된 검증자, 재실행된 코드 및 예상치 못한 발급자를 테스트합니다. RFC 9700은 클라이언트 유형별로 요구 사항과 권장 사항을 구분합니다.

    산출물: 허용 및 거부 테스트 결과.

  3. 3

    올바른 토큰 유효성 검사

    API는 형식 및 공급자 규칙(서명 또는 인트로스펙션, 발급자, 대상, 만료 및 권한)에 따라 액세스 토큰의 유효성을 검사합니다. OIDC 클라이언트는 ID 토큰을 별도로 검증합니다. 유효한 서명이 있다고 해서 해당 토큰이 이 API에 속한다는 것을 의미하지는 않습니다.

    산출물: 유효성 검사 계약 및 대상/만료 테스트.

  4. 4

    비즈니스 권한 확인

    다른 계정, 하위 역할, 개인 필드 및 관리 작업이 소유한 객체를 테스트합니다. 범위 또는 인증된 게이트웨이는 요청된 리소스에 대한 서버 측 검사를 대체하지 않습니다. 승인된 테스트 계정과 데이터를 사용하십시오.

    결과물: 역할, 객체, 작업 및 예상 거부 매트릭스

  5. 5

    만료 및 해지 테스트

    로컬 세션, 공급자 세션, 액세스 토큰 및 갱신 토큰을 분리합니다. 이탈, 장치 분실, 역할 변경, 서명 키 순환 및 공급자 장애를 테스트합니다. 로그아웃 시 모든 권한이 즉시 해지된다고 가정하는 대신 잔여 액세스 시간을 기록합니다.

    결과물: 액세스 제거 타임라인 및 예외 사항

  6. 6

    비밀 정보를 노출하지 않고 관찰

    트랜잭션 참조, 유효성 검사 결정, 오류 범주 및 구성 버전을 기록합니다. 코드, 토큰 및 비밀 정보는 제외합니다. 진단, 통합 종료 및 유효성 검사를 거친 구성으로 롤백을 준비하고 공급자 변경 후 테스트를 다시 실행합니다.

    산출물: 운영 절차 및 회귀 검사.

가상 예시

예시 상황

예시 상황: 두 클라이언트가 하나의 ID 공급자를 사용합니다. 첫 번째 클라이언트에 유효한 토큰이 두 번째 클라이언트의 API에 제공됩니다.

결정 및 예상 증거

API가 잘못된 대상을 거부하고, 토큰이 없는 추적을 기록하고, 데이터를 반환하지 않습니다. 이 거부는 회귀 테스트가 됩니다.

메커니즘 구분

메커니즘목적검증 또는 제한
OAuth 2.0리소스 접근 위임서버 측 객체 권한
OpenID Connect유효성이 검증된 ID 토큰을 통한 신원 확인발급자, 대상 및 트랜잭션 유효성 검사
애플리케이션 세션애플리케이션 로그인 유지만료, 무효화 및 세션 보호

관리 지표

지표측정 대상첫 번째 조치
거부 수정금지된 경우 실제로 차단됨모든 예상치 못한 승인 수정
권한 취소 지연관련 접근이 사라지는 시간세션과 토큰 별도 확인
유효성 검사 실패원인 및 버전별 거부공격과 구성 오류 구분

일반적인 실수

  • 인증과 권한 부여 혼동 방지
  • 서명 확인 후 모든 대상 허용
  • 광범위한 리디렉션 URI 등록
  • 토큰 로깅 디버깅 용이성 향상

자주 묻는 질문

PKCE가 모든 컨트롤을 대체하나요?

아니요. PKCE는 의도된 흐름에서 코드 교환을 보호합니다. 토큰 유효성 검사, 리디렉션, 비즈니스 권한 부여 및 세션은 여전히 ​​확인해야 합니다.

JWT는 권한인가요?

JWT는 형식입니다. 클레임은 유효성 검사 및 API 규칙 적용 후에만 사용 가능해집니다.

유효성 검사를 처음부터 구축해야 하나요?

유지 관리되는 라이브러리와 공급자 문서를 사용하는 것이 좋으며, 그 후 구성을 테스트하십시오. 올바른 라이브러리라도 잘못 구성될 수 있습니다.

공식 참조

참조는 방법을 뒷받침합니다. 상황에 맞게 검사를 조정하십시오. 이는 인증이 아닙니다. 원본 참조 제목 및 소스 문서는 다른 언어로 작성되었을 수 있습니다.