개요

Authorization은 클라이언트가 서버에 자신의 자격 증명(credentials)을 제시해 인증하는 요청 헤더입니다. 스킴(Basic·Bearer·Digest 등)과 그에 맞는 자격 값을 담으며, 보호된 리소스 접근의 핵심 수단입니다.

자세히

동작은 챌린지-응답 흐름을 따릅니다. 보호된 리소스에 인증 없이 접근하면 서버가 401 Unauthorized와 함께 `WWW-Authenticate` 헤더로 요구하는 스킴을 알려주고, 클라이언트는 그 스킴에 맞춘 Authorization 헤더를 붙여 재요청합니다. 인증은 성공했지만 권한이 없으면 403 Forbidden이 반환됩니다(401과 403의 구분).

가장 흔한 스킴은 두 가지입니다. Basic은 `user:password`를 base64로 인코딩할 뿐 암호화가 아니므로 반드시 HTTPS에서만 써야 합니다. Bearer는 OAuth 2.0/JWT 토큰을 그대로 실어 보내는 방식으로, 토큰을 가진 자가 곧 권한자이므로 토큰 유출은 계정 탈취와 같습니다.

이름은 'Authorization'이지만 실제로는 인증(authentication) 정보를 주로 담습니다. 프록시 인증은 별도 헤더인 `Proxy-Authorization`을 사용합니다.

문법

Authorization: <auth-scheme> <credentials>

e.g. Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

지시어 / 값

실무 참고

• Authorization 헤더가 붙은 응답은 기본적으로 공유 캐시에 저장되지 않습니다(민감 정보 보호).
• 리다이렉트 시 브라우저는 보안상 Authorization 헤더를 다른 오리진으로 전달하지 않을 수 있습니다.
• Bearer 토큰은 절대 URL 쿼리스트링에 넣지 마세요 — 로그·Referer·브라우저 기록에 남습니다.
• 쿠키 기반 세션과 Authorization 헤더는 CSRF 노출 특성이 달라, API에는 헤더 방식이 CSRF에 더 강합니다.

관련 헤더

관련 상태코드

스펙 근거