Basic·Bearer·OAuth 2.0·JWT·mTLS 등 인증 방식 10종. 동작 원리·전송 방식·보안 고려사항을 정리했습니다.
HTTP Basic 인증은 RFC 7617에 정의된 가장 단순한 인증 방식으로, 사용자 이름과 비밀번호를 콜론으로 이어 붙인 뒤 Base64로 인코딩해 Authorization 헤더에 담아 매 요청마다 보냅니다. 별도의 세션이나 토큰 발급 절차가 없어 구현이 쉽고, 내부 도구·헬스체크·프록시 인증 같은 곳에서 여전히 널리 쓰입니다.
Bearer 인증(RFC 6750)은 미리 발급받은 불투명(opaque) 토큰이나 JWT를 `Authorization: Bearer <token>` 헤더에 실어 보내는 방식으로, OAuth 2.0과 대부분의 최신 REST API가 표준으로 채택하고 있습니다. 이름 그대로 '토큰을 소지한 자(bearer)'가 곧 권한을 갖는다는 뜻입니다.
Digest 인증(RFC 7616)은 비밀번호를 평문이나 Base64로 그대로 보내지 않기 위해 만들어진 챌린지-응답 방식입니다. 서버가 nonce(일회성 값)를 던지면 클라이언트는 사용자 이름·비밀번호·nonce·요청 메서드·URI를 해시해 그 결과(response)만 전송하므로, 네트워크에 비밀번호 원문이 흐르지 않습니다.
API 키는 클라이언트(주로 서버·스크립트·SDK)를 식별하는 긴 무작위 문자열로, 보통 `X-API-Key`나 `Authorization` 헤더에 실어 보냅니다. 사용자 신원보다는 '어떤 애플리케이션·프로젝트의 호출인가'를 구분하고, 쿼터·요금·rate limit을 매기는 데 초점이 있습니다.
OAuth 2.0(RFC 6749)은 사용자가 자신의 비밀번호를 제3자 앱에 넘기지 않고도, 특정 리소스에 대한 제한된 접근 권한을 위임(delegate)하게 해 주는 인가(authorization) 프레임워크입니다. '구글 계정으로 캘린더 읽기 권한만 이 앱에 허용' 같은 시나리오가 대표적입니다.
OpenID Connect(OIDC)는 OAuth 2.0 위에 '인증(누구인가)' 계층을 얹은 표준입니다. OAuth가 '무엇을 할 수 있는가'만 다뤘던 빈틈을 메워, ID Token이라는 서명된 JWT로 사용자의 신원을 검증 가능한 형태로 전달합니다. 'Google/Apple/카카오로 로그인' 버튼 뒤에 있는 프로토콜이 바로 이것입니다.
JWT(JSON Web Token, RFC 7519)는 클레임(claim)들을 담은 JSON을 서명한 자기 완결적(self-contained) 토큰으로, `header.payload.signature` 세 부분을 각각 Base64URL로 인코딩해 점으로 잇습니다. 서버가 세션 저장소를 조회하지 않고도 서명만 검증하면 토큰 내용을 신뢰할 수 있어, 무상태(stateless) 인증의 사실상 표준입니다.
HMAC 서명 인증은 요청 자체를 공유 비밀키로 서명해, 보낸 주체의 신원과 요청의 무결성(변조되지 않음)을 동시에 보장하는 방식입니다. AWS Signature V4가 대표적이며, 결제·웹훅·서버 간 API처럼 요청 위변조와 리플레이를 막는 것이 중요한 곳에서 씁니다.
Mutual TLS(mTLS)는 일반 TLS가 서버만 인증서로 검증하던 것을 확장해, 클라이언트도 자신의 X.509 인증서를 제시하여 양방향으로 서로를 검증하는 방식입니다. 인증이 애플리케이션 계층이 아니라 전송 계층(TLS 핸드셰이크)에서 이뤄지며, 서비스 간 통신·제로 트러스트 네트워크·금융/IoT에서 강력한 신원 보증 수단으로 쓰입니다.
세션 쿠키는 전통적인 웹 로그인 방식으로, 로그인 성공 시 서버가 임의의 세션 ID를 발급해 `Set-Cookie`로 내려주고, 브라우저가 이후 모든 요청에 `Cookie` 헤더로 자동 전송합니다. 실제 사용자 상태(로그인 정보·권한)는 서버 측 세션 저장소에 두고, 쿠키에는 그 저장소를 가리키는 식별자만 담는 것이 정석입니다.