TIL 230620 : 쿠키, 세션, 토큰, JWT

인터넷을 하는 내 컴퓨터에는 쿠키가
접속하는 사이트 서버에는 세션이 있다.
다른 방법으로는 내 컴퓨터에 JWT라는 토큰을 가지고 있다.

---

인증과 인가

인증(좌) 인가(우)

인증 : 아~ 이런 분이시군요!

인가 : 이런 분이라고 하셔도 이건 안됩니다.

 

이 둘의 차이를 우선 명확히 해야한다.

Authentication, 인증. : 특정 사이트에서의 회원임을 확인받는 과정.

Authorization, 인가. : 이후 사이트의 여러가지 기능에 접근할 때 인증받은 걸 토대로 허가해주는 것.

 

 

쿠키와 세션

• 쿠키가 브라우저에 저장되면 해당 웹사이트를 방문할 때마다 자동으로 Request에 실어 보낸다.
  • 도메인별로 작동한다. (네이버에서 받은 쿠키는 네이버에만 보냄)
  • 유효기간이 있다.
• http프로토콜은 stateless하기 때문에 요청을 보낼때마다 그저 요청을 받아들일뿐 이전에 했던 요청과 연계되지 않음. 단골을 못 알아보는 느낌
• 처음 인증을 받을 때 쿠키에 SessionID를 담아서 주고, 세션DB에도 이를 저장한다.
• 이후에 해당 사이트를 접근할 때마다 받아두었던 SessionID가 쿠키에 담겨 보내지고, 이를 확인하여 인증을 한다.

 

JWT

• JWT는 따로 DB에 저장되지 않는다.
• 서버만 가지고 있는 Secret 키를 이용해 생성한 Signature가 포함된 토큰을 발행해 클라이언트로 준다.
• 이후 클라이언트에서 인증 정보와 함께 이 토큰을 보낸다.
• 서버에서는 Secret 키를 활용해 전달받은 인증정보를 통해 Signature값을 생성해보고 맞는 지 비교해본다.
  • 이 과정에서 복호화 없이 비교가능.

 

HEADER : 타입과 해싱 알고리즘이 들어있다.

PAYLOAD : 토큰에 담을 정보들. 한 조각을 클레임이라고 한다. 키-값형태로 존재.

Signature : 해당 헤더와 페이로드 데이터일시 가지게 될 수 있는 유일한 서명을 시크릿키를 통해 만들어서 같이 저장.

 

페이로드값을 수정해도 시그니쳐를 추측할 수 없기 때문에 조작이 불가하다.

하지만, 복호화자체는 쉬우므로 암호와 같은 민감한 정보를 담아선 안된다.

 

 

안정성?

JWT는 서버단에서 컨트롤이 불가능하다. 어디선가 탈취해가면 제어가 쉽지않다. 하지만 서버 측의 부하가 낮다.

쿠키-세션은 탈취당했을 때,  SessionID자체에는 주요정보가 없지만 이를 통해 클라이언트인척 할 수 있다.

 

여러가지 부가적인 방안들이 있지만 결국에 탈취당했을 때는 위험할 수 밖에 없다.

 

---

우리가 쉽게 사용하는 사이트를 생각해보면
구현만 하고 끝이 아니라
관리자 모드나, 인증/인가, 보안 등 신경써야할 게 너무 많다.
한 파트만 파고들어도 깊이가 꽤 되어 보인다.
내일 Spring Security 공부와 더불어 좀 더 파봐야할 듯 하다.

 

 

 

 

---

minor to study

좀 더 공부 및 복습해야할 개념들

 

Model :  바로 Request로 날라온 객체 받아주나?

addAttribute??

 

 

redirect : html파일로 주는 게 아니라 URL을 직접주는 방식

 

 

throw를 날리면 이후 코드는 실행이 어떻게 되는 지 + 예외처리되는 과정.