01
등록한 URI 원문 사용
리디렉션 URI의 포트, 경로, 끝 슬래시와 기존 쿼리까지 확인하세요. 전체 주소를 미리 인코딩하지 않습니다. 추가 매개변수는 줄마다 원문 key=value 형식으로 넣으며 값 안의 &도 그대로 입력할 수 있습니다.
OAuth 개발과 디버깅
OAuth 인증 URL와 콜백 분석
공개 예제로 요청과 응답을 살펴본 뒤 실제 설정을 입력하세요.
OAuth 인증 URL
요청 입력
원문 값을 입력하세요. 등록된 리디렉션 URI를 그대로 보존합니다.
결과
현재 브라우저 탭에서 처리하며 입력을 전송하거나 저장하지 않습니다.
옵션
response_type=code · 인가 코드 흐름
verifier는 토큰 요청용으로 보관하세요. URL에는 챌린지만 들어가며 보고서에는 verifier가 없습니다.
추가 항목은 줄마다 원문 key=value입니다. 미리 인코딩하거나 예약 필드를 반복하지 마세요.
값을 입력하거나 예제를 불러오세요.
로그인 오류가 토큰 처리 이전에 생길 수 있습니다. 콜백 포트나 끝의 슬래시가 달라졌거나 state의 더하기 기호가 공백으로 바뀌었다면 OAuth 인증 URL과 디코딩된 표를 비교해 보세요. 코드에서 보내려던 값과 실제 쿼리의 차이를 직접 확인할 수 있습니다.
이미 받은 테스트 콜백은 분석 화면에 붙여 넣습니다. 당시 보관한 예상 state를 별도로 입력하면 됩니다. 중복 이름을 하나의 속성으로 덮어쓰지 않으므로 첫 번째 값만 읽는 구현에서 놓친 문제도 드러납니다.
OAuth 인증 URL을 확인하는 이유
검증자는 요청 주소에서 분리
OAuth 인증 URL을 만들 때 입력한 verifier로 S256 챌린지를 계산합니다. 주소에는 챌린지와 방식만 들어가고 verifier는 입력란에 남습니다. 이후 토큰 요청에 사용할 값은 전용 버튼으로 복사하며 보고서에도 verifier는 포함하지 않습니다.
중복된 state를 그대로 확인
쿼리와 프래그먼트에 state가 함께 있으면 출처와 순서를 유지해 둘 다 표시합니다. 값이 같더라도 모호함으로 판정합니다. 하나의 일치 값이 다른 불필요한 매개변수를 가리지 않도록 하는 검사입니다.
요청 값을 잃지 않고 응답 확인하기
02
거래별 난수를 직접 갱신
생성 버튼은 state와 verifier에 각각 32개의 무작위 바이트를 사용합니다. scope에 openid가 있으면 nonce도 갱신합니다. 변경 필드 수와 후보를 검토한 뒤 적용하세요. 범위를 수정했다고 verifier가 자동 교체되지는 않습니다.
03
갱신 시점 선택
자동 모드는 입력이 멈춘 뒤 350밀리초 후 실행합니다. 끄면 실행 버튼 또는 Ctrl/Cmd+Enter를 사용합니다. 오래된 결과는 내보낼 수 없습니다. 화면을 전환해도 입력은 보존되지만 콜백의 예상 state는 별도 값입니다.
인코딩부터 상태 비교까지
중첩 주소를 하나의 값으로
내부 콜백 쿼리가 바깥 요청의 매개변수로 섞이지 않습니다. 엔드포인트의 기존 쿼리는 엄격히 디코딩해 보존하고 다시 인코딩합니다. 추가 값의 +는 %2B가 되고 공백은 폼 쿼리 형식으로 처리됩니다.
정확한 바이트로 S256 계산
verifier는 허용된 문자 43~128자로 구성해야 합니다. 양끝 공백을 지우거나 Base64부터 풀지 않습니다. PKCE를 끄면 요청에서 챌린지만 제거하고 입력은 유지합니다. 문법이 맞는 수동 문자열에 충분한 무작위성이 있다고 판정하지 않습니다.
출처를 남기는 콜백 분석
전체 URL, ?query, #fragment, 쿼리 문자열만 있는 입력을 지원합니다. %252F는 %2F까지만 풀고 %2B는 +로 바꿉니다. 빈 키와 값, 중복 행도 남아 있어 인가 코드가 어디서 왔는지 살펴볼 수 있습니다.
구체적인 state 비교
state 매개변수가 없거나 빈 경우, 여러 번 나오는 경우, 예상값이 없는 경우를 각각 표시합니다. code와 error가 섞여도 알립니다. 표는 50행씩 더 볼 수 있으며 보고서는 표시 행 수와 관계없이 전체 매개변수를 포함합니다.
지원 범위와 입력 제한
- 인가 코드 흐름만 구성
- response_type은 code로 고정합니다. implicit, hybrid, plain PKCE는 제공하지 않습니다. nonce를 입력하려면 openid 범위가 필요하며 실제 nonce 검증은 ID 토큰을 검증하는 앱에서 수행해야 합니다.
- URI 문법과 등록은 별개
- 인증 엔드포인트는 HTTPS를 사용합니다. 로컬 테스트용 localhost, 127.0.0.1, [::1]에는 HTTP도 허용합니다. 콜백은 com.example.app:/cb 같은 역도메인 앱 스킴도 지원합니다. 사용자 정보, 프래그먼트, 원시 공백, 잘못된 이스케이프는 거부합니다.
- 예약 필드 덮어쓰기 금지
- 기존 쿼리와 추가 줄의 중복 이름, 폼이 관리하는 OAuth 필드의 재지정은 오류입니다. 비밀 값, verifier, 토큰, 요청 객체와 response_mode도 넣을 수 없습니다. 제공자 프리셋, Discovery, JAR/PAR 및 form_post 수신은 범위 밖입니다.
- 분석은 로그인 검증이 아님
- 주소를 열거나 실시간 콜백을 받거나 코드를 토큰으로 교환하지 않습니다. 일반 앵커와 해시 라우터 경로도 지원하지 않습니다. state가 같아도 발급자, 서명, 세션 연결, 재사용 여부 및 인증 성공을 증명할 수 없습니다.
- 크기와 보관 제한
- 구성 입력의 합은 32,768자까지이며 콜백과 예상 state에도 각각 같은 제한을 적용합니다. 결과는 최대 100개 매개변수입니다. 기록과 초안은 저장하지 않습니다. 예제, 난수 교체, 초기화는 미리보기 후 적용하고 한 번 취소하면 입력과 결과가 함께 복원됩니다.
OAuth 인증 URL 질문과 답변
리디렉션 URI가 정확히 같아야 하는 이유는 무엇인가요?
스킴, 포트, 경로 또는 끝 슬래시가 다르면 다른 수신 주소를 가리킬 수 있습니다. 제공자 설정에 실제 사용할 URI를 등록하세요. 이 도구는 입력 원문을 값으로 보존하지만 등록된 클라이언트 설정을 읽지는 못합니다.
state와 nonce는 어떻게 다른가요?
state는 콜백 매개변수로 돌아와 저장한 거래 값과 비교합니다. nonce는 ID 토큰에 연결되어 해당 토큰을 검증한 다음 확인합니다. 붙여 넣은 콜백에서 nonce를 찾는 것만으로는 이 검사가 되지 않습니다.
클라이언트 시크릿이 있어도 PKCE를 사용해야 하나요?
시크릿은 토큰 엔드포인트에서 클라이언트를 인증합니다. PKCE는 인가 코드를 원래 verifier와 연결하는 별도 역할이 있습니다. 현재 권장 사항은 기밀 클라이언트에도 사용을 권합니다. 서버의 S256 지원 여부를 확인하세요.
클라이언트 ID를 URL에 넣어도 되나요?
네, 공개 식별자입니다. client_secret과 code_verifier는 역할이 다르며 인증 쿼리에 넣으면 안 됩니다. 도구는 해당 이름을 차단하고 verifier를 따로 복사하도록 합니다.
OAuth와 OpenID Connect는 무엇이 다른가요?
OAuth는 리소스 접근을 허가하고 OpenID Connect는 사용자 인증과 ID 토큰을 추가합니다. 요청 scope에 openid를 포함하고 제공자 조건에 따라 nonce를 지정하세요. 받은 토큰 검증은 앱에서 수행합니다.
계산 또는 검증 오류를 발견했나요?