[JWT] 웹 서버 인증 방식 총정리 (쿠키, 세션, 토큰, JWT)

1.Cookie 인증 방식

 

Cookie란?

쿠키는 Key-Value 형식의 문자열들이 모여있는 데이터이다.

클라이언트가 브라우저를 통해 방문한 사이트가 사용하고 있는 서버를 통해서 클라이언트의 브라우저에 설치되는 기록 정보 파일이다. 각 사용자마다의 필요한 정보를 서버단에서 저장하도록 하여, 각 클라이언트에게만 필요한 정보들을 클라이언트가 들고 있도록 하는 것

 

Cookie 인증 방식 설명

로그인에서 예를 들면, 로그인 성공시

“{“accessCookie” : “access1421DSFE23”}” 이런 식으로 클라이언트에게 서버에 인증할 수 있도록 전달해주고,

앞으로 이 사용자가 인가된 사용자인지에 대해 클라이언트 쿠키에서 “accessCookie” 키 값에 대한 Value를 서버에서 비교하여 일치한다면, 승인!

 

Cookie 인증 방식의 단점

1. 보안에 취약하다. 클라이언트가 인증 정보가 담긴 데이터를 쿠키로 받을때도, 인증하기위해 서버에 보낼때도 값을 그대로 보내며, 클라이언트가 서버에인증할 수 있는 정보를 그대로 브라우저에 가지고 있다는 것이 문제가 된다.
2. 쿠키에는 용량 제한이 있어 많은 정보를 담을 수 없다.
3. 브라우저에 종속적이다. 웹 브라우저마다 쿠키에 대한 지원 형태가 다르기 때문에 브라우저간 공유가 불가능하다.
4. 쿠키의 사이즈가 커질수록 네트워크에 부하가 심해진다. 인터넷이 느려졌을때 쿠키를 지우면 빨라지는 경험을 한 적이 있는데, 이런 이유였군!

 

별로 없지만 장점

1. 서버가 클라이언트의 인증을 위해 데이터를 가지고있어야하는 부담이 없다.

 

---

 

2. Session 인증 방식

Cookie 인증 방식의 가장 큰 문제인 보안 문제를 해결하고자 하는 인증 방식!

비밀번호 등 클라이언트의 민감한 인증 정보를 브라우저가 아닌 서버 측에 저장하고 관리

 

Session 인증 방식 설명

세션에는 사용자의 인증을 확인할 수 있는 정보가 담겨야하는데, 대표적으로

1. 세션 생성 시각
2. 마지막 접속 시간( 인증 요청이 왔을 때, 마지막 접속 시간으로부터 60분이 흐른 경우
3. 사용자 id

의 3개가 있다.

예를 들자면 아래와 같다.

session:{
	id : sessionid234TWR34
	creationTime : 2023-10-13-15:35,
	lastAccessedTime : 2023-10-13-15:57,
	userID : 서병렬
}

이러한 session 데이터를 각 사용자마다 서버에서 관리하

며 인증 로직에 제공된다.

만약 서버의 인증 규칙이 “사용자의 가장 최근 인증시각으로부터 30분까지 로그인상태가 유효하다.” 라고 정의되어있다면,

사용자의 인증요청이 2023-10-13-16:30에 왔는데,

마지막 인증된 시각이 2023-10-13-15:57 이였다면, 마지막 인증 시각으로부터 33분이 지났으므로 서버의 인증규칙에 의해 세션이 파기되며, 다시 로그인페이지로 리디렉션된다.

이런 민감정보들은 서버가 들고있으며, 브라우저단에는 서버에 저장된 Session들 중에서 나의 Session을 찾아야하니 쿠키에 SessionID 는 저장되어있어야한다! 인증시의 이 SessionID로 서버에 저장된 Session 을 찾아 인증을 시도한다.

 

Session 인증 방식의 단점

1. 세션 ID가 탈취되었을 때의 보안 문제를 해결하기 위해 서버단에서 추가 작업이 필요하다.
2. 서버에서 세션 저장을 위한 저장소를 사용하므로 요청이 많아지면 서버에 부하가 심해진다. 예를들면 현재 Session이 1000000개가되면 조회에 부하가 생긴다.

 

별로 없지만 장점

세션 ID 탈취 시나리오에 대한 대비만 되어있다면 보안이 취약하지 않다.

 

---

 

3. Token 인증 방식

Session 인증 방식의 단점을 극복하기 위해 고안된 인증 시스템으로,

쉽게 생각하면 보안 걱정 없는 쿠키 인증 방식이라고 이해할 수 있다.

 

Token 인증 방식 설명

사용자 로그인 → 서버측에서 클라이언트에게 유일 토큰 발급 → 클라이언트는 쿠키나 스토리지에 저장하여 HTTP요청시마다 헤더에 해당 토큰을 넣어서 같이 전달 →

 

이렇게하면 서버단에서 2개의 장점이 생긴다.

1. 위조될 염려가 없는 사용자의 인증정보를 검증하여 승인 or 거부한다.
2. 요청을 보낸 클라이언트의 정보(예를들면 이메일)와 같이 보낼 수 있기 때문에, 요청자가 누군지 서버단에서 바로 알 수 있다.

 

Token 인증 방식의 장점

1. 세션 인증 방식과 달리 인증정보의 상태를 유지, 갱신할필요가 없다(마지막 접속 시간 같이…)
2. 클라이언트에 종속되지않아 보안에 유리하며, 서버에도 저장소는 필요하지 않아 DB부하를 걱정할 필요가 없다.

 

Token 인증 방식의 단점

1. 토큰 자체를 탈취당할 염려가 있다.
2. 요청시마다 헤더에 포함하여 보내는 토큰의 길이가 길면 네트워크 요청에 부하가 걸릴 수 있다.

 

---

 

4. JWT 인증 방식

Json Web Token, 토큰은 토큰인데, 토큰 내의 인증에 필요한 정보들을 암호화시킨 Json 형식의 토큰이다.

위변조 방지를 위한 비밀키 전자서명도 들어있어 보안에 유리하다.

JWT 구조

JWT의 구조는 아래와 같으며

헤더.내용.서명 / Header.Payload.Signature

각 포함된 내용은 다음과 같다

• 헤더
  • 토큰 타입
  • 해시 알고리즘 종류
• 내용
  • 인증정보
• 서명
  • (헤더.내용, 비밀키) 문자열을 위의 빨간글씨 해시 알고리즘으로 암호화한 문자열

토큰의 내용(Payload)에 들어있는 데이터를 구분하자면

Registerd claims, Public claims, Private claims 세가지의 정보로 구분할 수 있는데, 각각

Registerd claims : 인증을 위해 정의된 내용(만료시간, 발행자 등)

Public claims : 공개용 정보

Private claims : 사용자 관련 정보

 

JWT 인증 설명

1. 로그인한 사용자에게 서버가 헤더.내용.서명을 Base64로 암호화하여 쿠키로 발급,
2. 클라이언트에서 쿠키에 저장 후 서버에 요청할때 HTTP 헤더에 담아서 보낸다.
3. 유효성 검증
   1. 내 서버에서 발행한토큰인지
   2. Signature를 이용한 위변조 검사
   3. 인증 만료 검증 → 만료시 클라이언트의 리프레시토큰을 이용하여 새로 토큰 발급

3.b.의 유효성 검증은 사용자가 헤더.내용.서명 의 토큰에서 내용을 변조하면 서버에서 변조된 토큰의 내용으로 서명 부분을 추출하여 유저가 보낸 변조된 토큰의 서명과 비교한다.

유저의 변조된 토큰의 서명과 서버에서 개인키를 포함하여 재암호화한 토큰의 서명은 같지 않으므로 유효하지않다!

 

JWT 인증 방식의 장점

1. Signature 검증으로 토큰 위변조 검증이 쉽다.(비밀키가 노출되지 않는 한)
2. Stateless한 인증방식으로 유지보수 및 확장에 유리
3. OAuth 가능, 접근권한 공유 가능 (아직 이해 못함)

 

JWT 인증 방식의 단점

1. 토큰 인증 방식의 단점에 이어 더욱 길어진 토큰의 내용으로 네트워크 부하 우려
2. 토큰 위변조로 서버에 접속하는 것은 막을 수 있으나, 토큰 복호화 후 내용을 볼 수 있어서 민감정보를 담고있지 않아야 한다.
3. 토큰 자체를 탈취당한경우 위인증 가능

 

토큰 탈취 에 대비하는 Refresh Token

JWT 인증 방식의 단점으로 토큰 자체를 탈취당한 경우의 보안상 문제를 꼽았는데, 똑똑한사람들이 이미 해결방법을 찾아놨다.

 

 

인증토큰이 만료되어있는데 재발급 토큰이 유효하다면, ......

너무 길다.. 다음에 수정..