OAuth 디버거

PKCE(Proof Key for Code Exchange, RFC 7636)는 원래 클라이언트 시크릿을 안전하게 저장할 수 없는 모바일 및 네이티브 앱을 위해 설계되었습니다. 클라이언트가 무작위 code_verifier를 생성하고, 이로부터 code_challenge를 도출(SHA-256 + base64url)한 다음, 인증 요청과 함께 챌린지를 전송하는 방식으로 작동합니다. 인증 코드를 토큰으로 교환할 때 클라이언트는 원래의 code_verifier를 전송합니다. 인증 서버는 이것이 이전 챌린지와 일치하는지 검증하여, 토큰 요청이 흐름을 시작한 것과 동일한 클라이언트에서 왔음을 증명합니다.

클라이언트 시크릿을 가진 기밀 클라이언트(서버 측 앱)라도, OAuth 2.1은 이제 인증 코드 가로채기 공격에 대한 방어책으로 PKCE 사용을 권장합니다.

암묵적 흐름(response_type=token)은 액세스 토큰을 URL 프래그먼트에 직접 반환하는, 싱글 페이지 앱을 위한 지름길로 설계되었습니다. 이는 심각한 문제를 일으킵니다. URL의 토큰이 브라우저 기록, 서버 로그, 리퍼러 헤더에 남으며, 이 흐름은 토큰 주입 공격에도 취약합니다. OAuth 2.0 보안 모범 사례(RFC 9700)와 OAuth 2.1은 암묵적 흐름을 명시적으로 제거하고, 클라이언트 시크릿 없이도 SPA가 안전하게 사용할 수 있는 인증 코드 + PKCE를 대신 권장합니다.

• 기밀 클라이언트를 포함한 모든 인증 코드 흐름에 PKCE가 필수입니다.
• 암묵적 흐름이 제거되었습니다 — 대신 인증 코드 + PKCE를 사용하세요.
• 리소스 소유자 비밀번호 자격 증명(ROPC)이 제거되었습니다 — password 그랜트 타입은 지원이 중단되었습니다.
• 공개 클라이언트는 리프레시 토큰 로테이션이 필수입니다 — 사용할 때마다 새 리프레시 토큰이 발급되어야 합니다.
• 리다이렉트 URI 정확 일치가 필수입니다 — 패턴 매칭이나 와일드카드는 허용되지 않습니다.

1. PKCE 쌍 생성: 무작위 code_verifier를 만들고 code_challenge = BASE64URL(SHA256(code_verifier))를 계산합니다.
2. 인증 엔드포인트로 리다이렉트: response_type=code, client_id, redirect_uri, scope, state, code_challenge, code_challenge_method=S256을 포함합니다.
3. 인증 서버에서 사용자가 인증하고 동의를 부여합니다.
4. 반환된 state와 함께 redirect_uri에서 인증 코드를 수신합니다 — state가 보낸 값과 일치하는지 확인하세요.
5. 코드를 토큰으로 교환: 토큰 엔드포인트에 grant_type=authorization_code, code, redirect_uri, client_id, code_verifier와 함께 POST 요청을 보냅니다.
6. 액세스 토큰을 수신하고(선택적으로 id_token과 refresh_token도) API 호출에 사용합니다.