Authorization

사용법

Authorization 요청 헤더는 보호된 리소스에 대한 접근 권한을 얻는 데 쓰이며, 보통 클라이언트가 접근이 제한되어 있음을 알게 된 뒤에 전송됩니다. 예를 들어 서버로부터 WWW-Authenticate 헤더를 포함한 401 Unauthorized HTTP 응답을 받은 뒤, 클라이언트는 이런 방식으로 자격 증명을 제출합니다.

참고

요청이 다른 오리진으로 리다이렉트되면 브라우저는 Authorization 헤더를 제거합니다. 이는 리다이렉트가 서드파티 서버를 가리킬 때 자격 증명이 유출되는 것을 막습니다. 이 동작은 WHATWG Fetch Standard에 정의되어 있으며 모든 최신 브라우저가 지원합니다. 교차 출처 리다이렉트를 넘어 Authorization 헤더에 의존하는 애플리케이션은 최종 목적지에서 재인증을 처리해야 합니다. curl, Python Requests, Go의 HTTP 클라이언트 같은 도구도 같은 관례를 따릅니다.

authentication-scheme

authentication-scheme은 필수 디렉티브이며, 선택적인 스킴별 매개변수가 함께 옵니다. 스킴은 자격 증명의 인코딩 방식을 정의합니다. 흔한 방식으로는 Basic, Bearer, Digest, Negotiate가 있습니다.

예시

이 예시에서 클라이언트는 basic 인증 스킴을 사용합니다. 필수 매개변수로서 자격 증명은 base64로 인코딩된 username:password 쌍입니다.

Authorization: Basic RXhhbXBsZTphaQ==

Bearer 토큰은 OAuth 2.0 API에서 흔합니다. 토큰은 인가 서버가 발급한 불투명 문자열이거나 서명된 JWT입니다.

Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...

문제 해결

인증 실패는 예기치 않은 401 응답이나 조용히 제거된 자격 증명으로 드러나는 경우가 많습니다.

교차 출처 리다이렉트에서 자격 증명이 제거됩니다. 요청이 다른 오리진으로 리다이렉트되면 브라우저와 HTTP 클라이언트는 Authorization 헤더를 제거합니다. 해결책은 자격 증명을 최종 목적지로 직접 보내거나 리다이렉트가 끝난 뒤 재인증하는 것입니다. curl -L -v 로 리다이렉트 체인을 살펴보고 헤더가 어디서 사라지는지 확인하십시오.

Basic 인증의 Base64 인코딩 오류. 인코딩된 문자열에는 사용자 이름과 비밀번호를 구분하는 콜론이 정확히 하나 있어야 합니다. 콜론이 빠지거나 이중으로 인코딩된 값은 서버가 거부하는 깨진 토큰을 만듭니다. echo -n “user:pass” | base64 로 원시 값을 확인하고 요청에서 보낸 헤더 값과 비교하십시오.

Bearer 토큰이 만료되었거나 형식이 잘못되었습니다. 토큰에는 만료 클레임이 들어 있으며 서버는 만료된 토큰을 401로 거부합니다. jwt.io 에서 또는 echo "" | base64 -d 로 JWT를 디코딩해 exp 필드를 살펴보십시오. 토큰 갱신 로직은 서버가 요청을 거부한 뒤가 아니라 토큰이 만료되기 전에 실행되어야 합니다.

서버가 WWW-Authenticate를 생략해 401 루프가 발생합니다. 서버가 401을 반환하면서 WWW-Authenticate 헤더를 포함하지 않으면, 클라이언트는 어떤 스킴이 요구되는지 알 수 없게 됩니다. curl -I https://example.re/resource 로 응답 헤더를 확인하고 서버 설정에 해당 헤더가 포함되어 있는지 점검하십시오. nginx에서는 auth_basic 디렉티브가 헤더를 자동으로 추가합니다. 직접 만든 백엔드는 헤더를 명시적으로 설정해야 합니다.

CORS 사전 요청이 Authorization 헤더를 차단합니다. Authorization을 실은 교차 출처 요청은 사전 요청 OPTIONS를 유발합니다. 서버는 사전 요청에 Access-Control-Allow-Headers: Authorization으로 응답해야 합니다. 값이 없거나 잘못되면 브라우저가 자격 증명을 보내기 전에 요청을 차단합니다. DevTools의 Network 탭에 사전 요청이 별도의 OPTIONS 항목으로 표시됩니다.

curl이 자격 증명을 엉뚱한 엔드포인트로 보냅니다. curl -H “Authorization: Bearer …” 를 -L 과 함께 실행하면 리다이렉트를 따라가지만 교차 출처 홉에서는 헤더가 제거됩니다. 정확한 엔드포인트로 헤더를 보내려면 -L 없이 curl -v 를 사용하거나, 리다이렉트를 넘어 자격 증명 전달을 강제하려면 —location-trusted 를 전달하십시오(신뢰할 수 있는 도메인에서만 주의해서 사용하십시오).

Basic 대 Bearer

Basic과 Bearer는 가장 흔한 두 가지 인증 스킴으로, 서로 다른 용도에 쓰입니다.

Basic은 모든 요청마다 Base64로 인코딩된 username:password 쌍을 보냅니다. 이 인코딩은 손쉽게 되돌릴 수 있으므로 HTTPS가 필수입니다. 자격 증명은 고정적이고 사용자 계정에 묶여 있어, 비밀번호가 유출되면 비밀번호 자체를 바꿔야 합니다. Basic은 토큰 관리가 불필요한 복잡성을 더하는 내부 도구와 단순한 연동에 적합합니다.

Bearer는 인가 서버가 발급한 불투명 토큰(흔히 JWT)을 사용합니다. 토큰은 만료되고, 범위가 지정된 권한을 담으며, 기반 비밀번호를 바꾸지 않고도 폐기할 수 있습니다. Bearer는 API와 OAuth 2.0 흐름의 표준 메커니즘입니다. 탈취된 토큰은 수명과 범위가 제한되어 있어, 유출된 비밀번호에 비해 피해 범위가 작습니다.

두 스킴 모두 헤더 값 안에 자격 증명을 평문으로 전송합니다. 어느 쪽도 그 자체로 암호화를 제공하지 않습니다. 어떤 스킴을 고르든 HTTPS가 필요합니다.

Fetch API로 Bearer 토큰을 사용하는 교차 출처 API 요청입니다.

fetch('https://api.example.re/data', {
  headers: {
    'Authorization': 'Bearer eyJhbGci...'
  }
})