HTTP 인증에 관한 개요

BASIC 인증

유저네임과 패스워드를 base64 의 형태로 인코딩하여 전송하고 서버는 이를 디코딩하여 인증을 확인한다.

형태는 다음과 같다.

username = 'foo'
password = 'supersecretpassword'

credentials = `${username}:${password}`
encoded = base64.encode(credentials)
request.headers.Authorization = `Basic ${encoded}`

장점

• HTTP 기본 인증 프로토콜로 대부분의 브라우저에서 지원
• 구현이 간단함

단점

• base64로 인코딩 되기 때문에 패킷 탈취 시에 보안에 매우 취약함. (SSL 반드시 필요)

 

---

 

DIGEST 인증

Basic 인증을 기반으로 보안을 강화한 인증방식.

서버에서 무작위의 nonce 값을 클라이언트에 제공하고 클라이언트에서는 nonce를 조합하여 MD5 형식으로 암호화하여 서버에 전송한다. 서버는 저장된 nonce 값이 일치하는지 확인 후 데이터를 복호화하여 인증을 획득

Hash1=MD5(username:realm:password)
Hash2=MD5(method:digestURI)
response=MD5(Hash1:nonce:Hash2)

request.headers.Authorization = `Digest username=${username}, response=${response}, nonce=${nonce}...`

장점

• HTTP 기본 인증 프로토콜로 대부분의 브라우저에서 지원
• 구현이 간단하고 BASIC 인증보다 보안이 강회됨

단점

• MD5는 보안에 취약한 암호화 방법이므로 최근에는 마찬가지로 보안에 취약함

 

---

 

폼 인증

오늘날 대부분의 서비스에서 사용되는 인증방식. HTTP에 등록된 인증방식이 아니라 통일된 프로세스는 아직 존재하지 않으나, 잘 갖추어 놓을 경우 가장 보안이 뛰어나다.

SSL과 함께 사용되며 최초에 유저네임과 패스워드를 BODY에 담아 인증을 받고 이후에는 세션 이나 토큰 을 통해 사용자 인증을 획득한다.

 

---

 

세션

사용자 정보가 일치하는 경우 임의의 문자열을 생성하여 유저 정보와 만료기간을 함께 스토리지에 저장한 후 HTTP 쿠키에 담아 클라이언트에게 반환한다.

장점:

• 세션정보는 서버에서만 관리하기 때문에 제 3자에 의한 데이터 변조를 방지할 수 있다.
• 패킷이 탈취되더라도 세션은 의미가 없는 임의의 문자열이기 때문에 안전하다.
• 세션 스토리지가 노출되더라도 세션에는 민감한 정보가 담기지 않기 때문에 안전하다.

단점:

• 서버에서 세션정보를 저장/유지할 스토리지가 필요하므로 사용자가 많은 서비스의 경우에 상당한 추가 메모리나 저장공간이 필요하다.
• 트래픽이 몰릴 경우에 세션정보를 조회로 인해 성능 하락이 발생할 수 있다.
• 기본적으로 쿠키는 Same-Origin에서 작동하게 설계되어 있어 도메인이 다른 경우 관리에 번거롭다.

 

---

 

토큰

세션과 비슷하지만 임의의 문자열이 아닌 만료일과 정보를 담은 문자열을 암호화와 복호화 과정을 거쳐 인증을 획득합니다. 또한 서버에서 관리되는 세션정보와는 달리 토큰은 클라이언트 측에서 저장하고 관리합니다. JWT 인증 방식이 대표적입니다.

 

리프레시 토큰의 보안 유지에 관한 내용이 정리된 좋은 포스팅을 공유한다.

What Are Refresh Tokens and How to Use Them Securely

장점

• Stateless. 상태 정보를 서버에서 저장하지 않기 때문에 스토리지가 필요하지 않습니다.
• 스토리지를 사용하지 않기 때문에 서버 확장성에 유리하다.
• 짧은 만료기간을 통해 access_token 이 탈취돼도 보안 위험이 적습니다.
• refresh_token을 통해서 재인증을 시도하므로 사용자의 빈번한 재인증이 필요하지 않습니다.
• 세션과 달리 쿠키 등을 사용하지 않으므로 CORS에 자유롭다.
• 쿠키에 의존하지 않으므로 플랫폼에 자유로움

단점

• 일반적으로 토큰의 길이는 꽤 긴 편이라 네트워크 낭비가 발생.
• 개별 토큰에 대한 무효화가 불가능하다.
• 클라이언트에 저장되므로 XSS 공격에 취약하다.

 

 

세션 인증 VS 토큰 인증 언제 사용해야 할까?

Auth Headers vs JWT vs Sessions - How to Choose the Right Auth Technique for APIs | HackerNoon

Auth Headers vs JWT vs Sessions — How to Choose the Right Auth Technique for APIs | HackerNoon

1. 특정 조건에 의해 인증을 무효화할 수 있어야 한다. - 세션 인증
2. 고정된 시간이 아닌 로그인이 비활성화될 때 인증이 만료되어야 한다 - 세션 인증
3. 단일 플랫폼 서비스이다 - 세션 인증
4. 다중 플랫폼 서비스이기 때문에 모바일 등의 다양한 환경에서의 유저 인증이 지원이 필요하다 - 토큰 인증