도구보다 역할 먼저 선택하기
OAuth 액세스 토큰은 불투명하거나 JWT를 사용할 수 있습니다. JWT 디코딩은 진위를 검증하지 않으며 서명된 JWT가 내용을 자동 암호화하지도 않습니다. 게이트웨이는 서비스 내부의 업무 인가를 대신하지 않습니다.
| 요소 | 역할 | 명시할 한계 |
|---|---|---|
| OAuth 2.0 | 위임된 인가. | 그 자체로 사용자 로그인 프로토콜이 아님. |
| OpenID Connect | OAuth 2.0 위의 인증. | 프로파일 및 토큰 검증 필요. |
| JWT | 클레임 형식. | 디코딩, 서명과 암호화는 다름. |
| API 게이트웨이 | 공통 진입 통제. | 객체별 권한을 대신하지 않음. |
프로토콜과 모든 접근 검증하기
- 클라이언트에 맞는 흐름을 선택합니다. 사용자 경로에는 유지보수되는 라이브러리와 엄격한 리디렉션 관리로 현행 인가 코드 및 PKCE 권고를 따릅니다.
- 수용하는 JWT의 서명, 허용 알고리즘, 발급자, 대상과 프로파일 시간 조건을 검증합니다. 다른 용도의 토큰은 거부합니다.
- 각 객체, 작업과 조직의 권한을 확인합니다. 가상 데이터로 계정 간 접근을 테스트합니다. 일반 역할이나 범위만으로 충분하지 않을 수 있습니다.
만료, 취소와 사고도 계획하기
갱신, 키 교체, 비밀 유실과 취소 전략을 문서화합니다. 로컬 검증은 원격 취소를 자동으로 알지 못합니다. 토큰 정보와 로그를 최소화합니다. JWT나 할당량만으로 보안 또는 규정 준수를 보장할 수 없습니다.
1차 자료
- IETF RFC 9700 — OAuth 2.0 Security Best Current Practice [EN]
- IETF RFC 8725 — JWT Best Current Practices [EN]
- OpenID Foundation — OpenID Connect Core 1.0 [EN]
- OWASP — Authorization Cheat Sheet [EN]
게이트웨이는 객체 권한 부여를 대체하지 않습니다.
API는 토큰이 해당 API를 위한 것인지, 그리고 호출자가 해당 객체에 대한 작업을 수행할 수 있는지를 모두 확인해야 합니다. 유효한 JWT 서명이나 성공적인 OAuth 로그인만으로는 해당 권한이 부여되지 않습니다. 인접 계정 및 특권 기능을 테스트하십시오.
- 다른 사용자를 대상으로 하는 유효한 토큰을 거부하십시오.
- 계정 간 액세스, 비공개 필드 및 관리자 작업을 테스트하십시오.
- 토큰을 로그에 기록하지 않고 만료 및 역할 변경을 실행하십시오.
1차 자료: IETF — RFC 9700, OAuth 2.0 Security Best Current Practice. 관련 방법: 실무 가이드 읽기.
패스키: 도메인과 RP ID 변경 준비
계정, 웹 출처와 RP ID를 구분해 인증 정보를 조용히 다시 연결하지 않는 전환을 준비합니다.
- 이전과 새 출처, RP ID와 연결 계정을 기록합니다. 같은 계정 이름이라고 패스키가 다른 RP ID에 유효해지지는 않습니다. WebAuthn의 허용 조합과 전환 중 가능한 접근 경로를 확인합니다.
- 허가된 시험 환경에서 적절한 라이브러리로 챌린지, 출처, RP ID와 계정 연결을 확인합니다. 예상 밖 출처와 재사용 챌린지를 시험합니다. RP ID가 바뀌면 인증된 새 등록을 준비합니다. 행 복사를 키 이전으로 취급하지 않습니다.
- 이전 인증 정보만 가진 사용자, 복구와 열린 세션을 시험합니다. 검증된 복귀와 함께 경로 개설과 종료 순서를 정합니다. 새 도메인 등록 성공이 모든 이전 세션의 폐기를 입증하지는 않습니다.
재현 가능한 수락 사례
가상 예시입니다. 고객이나 실제 관측 결과를 나타내지 않습니다.
사례 입력 보기
{
"old_origin": "https://login.old.example",
"old_rp_id": "old.example",
"new_origin": "https://login.new.example",
"new_rp_id": "new.example",
"same_service_account": true,
"expected": "authenticated_new_registration"
}예상 판단
가상 예: 계정은 같지만 old.example에서 다른 RP ID의 new.example로 옮깁니다. 이전 인증 정보를 조용히 다시 연결하면 안 되며 새 등록은 계획한 인증 경로를 따라야 합니다.
데이터베이스를 수정해 패스키 RP ID를 바꿀 수 있나요?
아닙니다. RP ID는 검증되는 인증 정보 범위의 일부입니다. 새 범위에서 유효한 등록과 인증된 계정 연결을 준비하세요.
1차 자료: W3C — Web Authentication Level 2. 관련 방법: 실무 가이드 읽기.
TLS 갱신: 실제 제공 인증서 검증
갱신을 TLS 종료 지점과 클라이언트까지 확인한 뒤 변경을 완료합니다.
- 이름, CDN, 로드 밸런서, 프록시와 인증서를 제공하는 내부 연결을 기록합니다. 실제 인증서, 체인, 만료와 담당자를 확인합니다. 발급 성공이 모든 노드 설치를 입증하지는 않습니다. 개인 키를 보호하고 목록에 넣지 않습니다.
- 제공된다면 공급자 시험 환경에서 자동화를 확인합니다. 검증 챌린지, SAN 이름, 보호 저장소와 다시 로드를 확인합니다. 키 정책상 사용 가능한 인증서가 있으면 시작마다 발급하지 않습니다.
- 지원 클라이언트와 관련 경로에서 이름, 날짜와 신뢰 체인을 검증합니다. TLS 검증을 유지합니다. 스케줄러만 아닌 실제 인증서 만료를 감시합니다. 복귀는 유효 인증서와 침해되지 않은 키가 필요하며 아니면 수정하거나 격리합니다.
재현 가능한 수락 사례
가상 예시입니다. 고객이나 실제 관측 결과를 나타내지 않습니다.
사례 입력 보기
{
"issuance_succeeded": true,
"proxy_count": 2,
"proxies_serving_expected_certificate": 1,
"other_proxy_certificate_expired": true,
"tls_verification_enabled": true,
"expected": "change_incomplete_fix_and_verify_client_paths"
}예상 판단
가상 예: 갱신은 성공했지만 두 프록시 중 하나가 만료 인증서를 제공합니다. 변경은 미완료이며 프록시를 고치고 TLS 검증을 끄지 않은 채 경로를 확인합니다.
1차 자료: Let’s Encrypt — Integration Guide. 관련 방법: 실무 가이드 읽기.
CISA KEV 목록 살펴보기
이 언어판의 상세 참고 설명은 영어로 제공됩니다.
One identifier can span several technical layers
An entry may concern a library, server or component embedded in an appliance. Search the exact name, known dependencies and the distributed product’s advisory. Catalogue aliases are not a complete list of affected versions.
- Connect the CVE, component supplier and final-product supplier.
- Check version, configuration and execution path in the authorised environment.
- Do not infer remediation from an empty search result.
CISA KEV · 2026.11.06 · Documentary review : 2026-11-07
확장 프로그램: 권한과 접근
이 언어판의 상세 참고 설명은 영어로 제공됩니다.
Robust authentication does not describe extension access
Phishing resistance does not remove the need to examine what runs in the browser after a session opens. A manifest provides clues about cookies, scripting, debugging and identity without establishing collection.
- Test approved extensions in a profile dedicated to sensitive operations.
- For identity, inspect OAuth scopes and recipients; this permission does not enumerate identity-provider rights.
- Distinguish session revocation, token revocation, extension disablement and native-component removal.
Read the permission directory and manifest examples →
Google Chrome · Stay secure · Documentation consulted 2026-10-23; browser behaviour remains version-dependent