쿠키 세션 토큰 JWT

쿠키

그냥 옮기는 매개체

쿠키를 이용해서 서버는 브라우저에 데이터를 저장(너에 관한것을 기억하기 위해서)

브라우저에 쿠키를 저장한 후, 요청을 보낼 때 마다 쿠키도 같이 보냄

 

쿠키 특징

• 쿠키는 도메인에 따라 제한이 됨 (예를 들면, 유튜브가 준 쿠키는 유튜브에만 보내지게 됨)
• 유효기간이 있음 (서버가 정한 기간에 따라 유효함)
• 인증뿐만 아니라 여러 정보를 저장할 수 있다 (예를 들어 웹사이트 언어설정을 바꾸면 서버는 쿠키에 언어설정을 저장하고, 나중에 요청을 보낼때 쿠키안의 언어로 응답을 받게 됨)

 

💡 http 프로토콜은 stateless이기 때문에 서버는 누가 요청을 보내는건지 모른다
⇒ 요청할 때 마다 우리가 누구인지 알려줘야함
⇒ 그 방법들이 바로 세션, 토큰

세션

영화표 반쪽은 브라우저에, 반쪽은 서버에

쿠키 안에 세션ID를 저장 (쿠키는 그저 세션ID를 전달하기 위한 매개체 일 뿐)

 

로그인

yuyu유저명과 비번을 서버에 보냄

⇒ 비번이 맞으면 서버는 세션DB에 yuyu라는 유저를 저장하고, 쿠키를 통해 해당 세션ID를 브라우저에 전달.

요청을 할때 서버는 쿠키 안의 세션ID를 확인하고 세션DB에서 해당유저를 찾으면 인증이 되는것임.

 

중요한 유저정보는 모두 서버에 있고, 유저가 갖고 있는것은 세션ID뿐

 

💡 안드로이드, ios앱을 만들 때 세션을 이용할 수 있지만 쿠키는 사용할 수 없음 (쿠키는 브라우저에만 있기 때문) ⇒ 이 경우에 토큰을 사용함

 

토큰

서버가 기억하는 이상하게 생긴 string

서버에서 토큰을 받아서 요청할 때 마다 보냄

서버에 토큰을 보내면, 서버는 세션DB에서 해당토큰과 일치하는 유저를 찾음

 

💡 세션의 중요한 점은 로그인한 유저들의 모든 세션ID를 DB에 저장해야한다
⇒ 요청이 들어올때마다 서버는 쿠키에서 세션ID를 보고, 그와 일치하는 유저를 찾아야함 (요청이 있을때마다 DB탐색해야함)
⇒ JWT

 

JWT (Json Web Token)

찢지 않은 영화표 토큰을 그냥 브라우저에 줘버리고 서버는 기억하지 않음

정보를 갖고있는 토큰 (DB없이 검증할 수 있음)

 

토큰 형식

• 유저인증을 할때 세션DB탐색 할 필요없음 (서버가 할 일을 줄여줌)
• 세션ID보다 김 (크기 제약이 없음, 쿠키는 있음)
• 암호화되지 않음 (비밀정보를 JWT에 두면 안 됨)

https://jwt.io/

JWT.IO

 

로그인

유저명, 비번을 서버에 보냄

⇒ 맞다면 서버는 DB에 뭔가를 생성하지 않음, 대신 (예를 들어) 사인된 형태의 유저명을 브라우저에 보냄

 

요청할때

세션ID처럼 토큰을 서버에 보냄

⇒ 서버는 토큰을 받으면 유효한지 조작한건지 체크하고, 유효하다면 서버는 우리를 유저로 인증한다.

 

세션과 JWT의 차이점

세션은 인증하기 위해 DB에서 찾아야하는데,

JWT는 DB를 건들이지 않고, 사인된 토큰을 통해 인증함

	세션	JWT
서버가 주는 것	세션ID	엄청 긴 토큰
인증법	세션ID를 DB에서 찾음	토큰의 유효성 검사 (DB거칠 필요 없음)
장점	서버는 세션DB에 로그인된 유저의 정보를 저장함 ⇒ 세션을 삭제해서 강제로그아웃, 넷플릭스처럼 계정공유 숫자를 제한 할수 있음	DB 없이 유저인증 가능
단점	DB유지 (보통 redis(길다란 공용책상)를 사용, 빠르고 저렴한 DB)	강제로그아웃이런거 할 수 없음

 

 

---

 

authentication 인증 (로그인)

authorization 인가 (로그인된 상태가 할 수 있는 일)