JWT, Session 인증에 대해

1. 기존 방식

아이디, PW를 저장해놓고 계속 서버로 쏘는 방식 → 단점: 한번 탈취당하면 큰일난다.

2. 세션 인증 방식

아이디, PW를 받으면 서버가 세션을 생성한다. 세션 아이디 기준으로 정보를 저장함.

세션을 저장해놓는 세션 저장소가 있음.

사용자는 세션 아이디를 로컬에 저장한다.  
사용자는 서버에 요청을 보낼 때마다 쿠키에 있는 걸 전달하고, 서버는 세션아이디가 서버에 저장된 형태인지 확인한다.

장점: 탈취된 세션의 경우 세션을 강제 만료시킬수 있다.  
단점: 세션이 많아지면 복잡해짐, 만약 유저가 1000000000명이 동시에 로그인한다면?! 

3. JWT 인증 방식

세션이 서버에 인증 정보를 기록했다면 토큰은 인증받은 사용자에게 부여해서 인증 정보를 사용자가 가지고 있음.

헤더, 페이로드, 서명으로 토큰은 구성되어 있음. 서명은 헤더와 페이로드에 있는 값을 헤더에 있는 방법으로 암호화한 값이다.

헤더와 페이로드는 특별히 암호화되지 않기 때문에(Base64를 사용해서 바로 해독됨) 그 부분에 유저의 중요한 정보를 넣어두면 안 됨.
서버가 가지고 있는 키로 서명을 복호화한 다음에 앞에 있는 헤더와 페이로드와 일치하는지 확인한다. 일치한다면, 내 서버에서 발행한 토큰임을 인증되는 셈이다.

 

단, 이때 명심해야 할 점은 JWT는 정보 보호보다는 인증의 목적이 강하다.

특정 토큰을 만료시키기 어렵지만, 인증에 대한 별도의 저장소가 필요없다.

 

4. RefreshToken, AccessToken을 이용한 인증 방식

accessToken : 클라이언트가 가짐
refreshToken: 서버가 저장

accessToken이 expired됨 → refreshToken을 사용해서 검증되면 재발급 → 기존의 refreshToken은 삭제

따라서 세션과 Token 두 가지를 모두 잡을 수 있다.

---

번외) Cookie, LocalStorage, SessionStorage의 차이

크롬 기준 관리자도구 > 애플리케이션에서 확인해볼 수 있다. 

 

1. 쿠키 : 만료 기간이 있는 Key, Value 형태의 저장소 → 팝업창의 다시보지않기 등에 활용

• 암호화가 안돼서 탈취 위험
• 매 HTTP요청마다 포함돼서 서버에 부담
• Set-Cookie에 내용을 넣어서 전달하면 브라우저가 이 내용을 자체적으로 저장. 그리고 Cookie 요청 헤더에 넣어서 함께 전달함.
• 용량이 작다

2. LocalStorage: 브라우저 창을 닫더라도 데이터가 유지. (자동로그인 등에 활용)

3. Session Storage: 브라우저를 닫으면 영구적으로 데이터 삭제 → 장바구니

 

 

---

간략하게 정리해보았다.

아래 글이 무척 잘 정리되어있으므로 추천

https://inpa.tistory.com/entry/WEB-%F0%9F%93%9A-JWTjson-web-token-%EB%9E%80-%F0%9F%92%AF-%EC%A0%95%EB%A6%AC