인증 방식(세션-쿠키, JWT 토큰)

오랜만에 쓴다 ㅎㅎ 오늘의 주제는 인증 방식들! 각각을 설명하고 마지막에 살짝 비교하면서 정리하려고 한다.
인증 방식은 싸피에서도 배웠고, 프로젝트 하면서도 많이 사용했다. 그런데 회사 면접에서 이에 대한 질문을 받은 적이 있는데, 막상 질문 받으니 헷갈리는 것도 있었다..ㅠ
정리해보고 싶어서 주제를 선택했다~~

인증과 인가

일단 인증이 뭘까? 비슷한 단어인 인가와 함께 살펴보자!

• 인증(Authentication): 사용자의 상태가 어떤지(로그인 여부), 사용자가 누구인지 확인하는 것
• 인가(Authorization): 인증 받은 사용자의 권한을 확인하는 것

인증은 사용자의 상태가 어떤지 즉 로그인했나 안했나, 로그인했으면 그 사용자가 누구인지를 확인하는 것이다.
인가는 인증 받은 사용자가 어떤 일을 하려고 할 때 그 일을 할 수 있나 권한을 확인하는 것이다. 예를 들어서 사용자가 어떤 게시물을 삭제 하는 요청을 보내면, 그럴 권한이 있는지 체크해야 한다.

인증 방식이 필요한 이유

인증 방식들이 왜 필요할까?? http 통신을 사용하는데, http 통신은 stateless 하기 때문이다! stateless 는 상태가 없다는 말이다. 이 건 요청들이 각각 ~~ 독립적으로 다뤄진다는 것이다. 하나의 요청이 끝나면 서버는 요청한 사람이 누군지 잊어버린다.
네이버에서 메일 하나 보고, 다른 메일 보려고 하는데 또 로그인하라고 한다면?? 너무 불편할 것이다.
서버에 뭔가 요청할 때마다 서버에게 요청하는 사람이 누군지 알려줘야 하는데, 그러기 위해서 이제부터 설명할 인증 방식들이 필욯다ㅏ!
인증을 통해서 서버는 유저가 누구인지 알 수 있다.

쿠키, 세션 방식

쿠키

• 쿠키는 서버에서 브라우저로 전달한 작은 데이터이고, 서버- 클라이언트 사이에서 소통하는 수단이 된다.
• 다음과 같은 순서로 쿠키가 활용된다 !! 사이트에 방문→ 브라우저가 서버에 필요한 요청을 함 → 서버는 응답을 줌. 이때 쿠키가 있을 수 있음 → 브라우저는 쿠키를 받으면 브라우저에 저장함. → 그 사이트에 방문해서 요청 보낼 때마다 쿠키를 함께 보냄.
• 특정 도메인에서 생성된 쿠키는 그 도메인에서만 사용된다. 예를 들어서 네이버에서 생긴 쿠키는 네이버에서만 사용되고, 다음에서 생성된 쿠키는 다음에서만 사용된다.
• 참고로 크롬 익스텐션 (Cookie-Editor)을 사용하면, 그 도메인에서 받아서 브라우저가 저장하고 있는 쿠키를 쉽게 볼 수 있다!!

(네이버 사이트에서 Cookie-Editor 익스텐션을 켠 후 캡쳐함)

• 또 쿠키는 인증에만 쓰이는 게 아니라, 다른 데에도 쓰일 수 있다. (예- 웹 사이트 언어 설정, 팝업 일주일 간 보지 않기, 장바구니 등등). 보안과 관련 없을 때는 쿠키만으로 처리 가능하다!!
• 그렇지만 !!! 쿠키만으로 인증을 하지는 않는다. 만약에 쿠키 만으로 인증을 한다면 ? 쿠키 안의 정보가 조작될 수 있고, 중간에 해커가 http 요청을 가로채면 민감한 정보도 빼앗기는 것이다ㅠㅠ 그래서 안전하게 인증하기 위해서 쿠키, 세션을 같이 사용한다. 클라이언트는 서버에 요청보낼 때 쿠키를 같이 보내고, 서버는 이 쿠키를 받아서 세션 정보에 접근하는 식으로 인증한다.

쿠키-세션 인증 과정

(아래 참고 자료들을 정리해서 미리 캔버스에서 만들었다 !)

장점

1. 로그인한 유저의 상태를 제어 가능하다. 로그인한 모든 디바이스 보여주기, 원치 않는 디바이스에서 강제 로그아웃 시키기, 한 계정으로 하나의 기기에서만 접속되게 하기 등등이 가능하다.
2. http 요청 노출되어서, 쿠키에 있는 세션 아이디 값을 탈취당해도 그 값 자체는 큰 의미가 없다! 중요한 정보는 서버에 있다.
3. 쿠키에 있는 세션 아이디는 고유한 값이라서, 어떤 회원인지 바로 확인 가능하다!

단점

1. 로그인한 유저들의 모든 세션 정보를 저장할 DB 공간이 필요함.
2. 서버 부하가 생길 수 있음(인증을 해야 할 때마다 매번 세션 저장소에 접근해야 함)
3. 세션 하이재킹 공격(로그인된 상태를 가로채는 것) 해커가 http 요청에서 세션 아이디가 포함된 쿠키를 훔칠 수 있음. 이를 가지고 서버에 요청을 보내면, 서버가 그 사용자인 줄 알고 잘못 처리할 수 있음 ⇒ https를 이용해 요청 탈취 당해서 정보 읽기 어렵게 만들기.

Json Web Token 토큰 기반 인증

토큰: 암호화된 문자열

JWT 토큰 : JSON Web Token. 인증에 필요한 정보를 암호화한 토큰.

• 마침표 기준으로 세 부분으로 나뉜다.

1. 헤더(header): 암호화하는 알고리즘 방식(서명 값 만들 때 사용할 알고리즘), 토큰의 타입
2. 페이로드(payload): 서버에 보낼 데이터. 유저 아이디, 토큰의 유효기간, 관리자인지 여부 등
3. 서명(verify signature): 헤더, 페이로드, 시크릿 키를 더한 뒤 서명한 값. 시크릿 키는 서버만 알고 있다. 클라이언트에서 JWT 토큰을 받은 뒤, 유효성 검증을 할 때 사용한다.

• 헤더, 페이로드는 디코딩해서 확인할 수 있다. 페이로드에 민감한 정보를 보내면 안된다!
• 관련 사이트: https://jwt.io/ jwt에 대한 설명도 있고, 페이로드 값, 시크릿 키 값, 알고리즘을 입력한 뒤 인코딩된 JWT 토큰 값을 볼 수도 있다 ~!!

JWT 토큰 인증 과정

(아래 참고 자료들을 정리해서 미리 캔버스에서 만들었다 !)

장점

1. 별도의 저장소가 필요하지 않다.
2. 확장성: oauth 로그인 등 토큰 기반 인증 시스템을 사용할 때 확장성 면에서 좋다고 한다.. (이 부분은 안해봐서 잘 모르겠다..)

단점

1. 이미 발급된 토큰은 유효 기간이 지날 때까지 계속 사용이 가능함. (토큰이 탈취된 것 알아도 강제 로그아웃 못 시킴)
2. ⇒ 대책: access token은 유효 기간을 짧게 하고, refresh token은 유효 기간을 길게 해서 사용하는 방법이 있다. 그렇다고 해도 accee token 이 만료되지 않은 동안은 사용될 수 있다.ㅠ
3. payload에는 중요한 정보를 넣지 못한다.
4. jwt 토큰 길이가 길어서, 서버의 자원 낭비가 발생한다고 한다~

세션-쿠키 vs. JWT 토큰

세션-쿠키 방식에서는 세션 저장소에 유저 정보를 저장한다. ↔ JWT 토큰 방식에서는 토큰 안에 유저 정보가 있다.

클라이언트는 세션-쿠키 방식의 경우 쿠키를, JWT 토큰 방식의 경우 access token을 실어서 서버에 요청을 보낸다.

서버는 세션-쿠키 방식의 경우 쿠키의 세션 아이디를 통해서 세션 저장소에 접근해서 어떤 유저인지 파악하고, JWT 토큰 방식의 경우 JWT 토큰을 decode해서 토큰이 조작되었는지, 기간이 만료되었는지, 유저가 누구인지 파악한다.

웹 사이트 규모, 사용자 계정을 어떻게 관리할 것인지(1계정 1기기 로그인 등이 필요한지 등) 등에 따라서 인증 방식을 선택해야 한다~

참고 자료

Cookie, Session, Token 의 차이점

쿠키, 세션, 토큰에 관하여

https://www.youtube.com/watch?v=tosLBcAX1vk

https://www.youtube.com/watch?v=1QiOXWEbqYQ

[HTTP] 쿠키, 세션, JWT

• 이미지는 미리캔버스에서 만듦.

읽어주셔서 감사합니다 ~ ~
공부해서 정리한 내용입니다.
혹시 틀린 내용이 있다면 댓글로 알려주세요 :)

 

아 그리고 난 지금까지프론트에서 access token을 브라우저의 local storage나 session storage에, refresh token을 local storage에 저장했다. 이걸 다른 곳에 저장하는 방식도 있다고 들었는데 더 알아보고 싶다.. 다른 분들은 어디에 저장하시는지도 궁금하다..ㅎㅎ 댓글로 어디에 저장하시는지 알려주세용 ㅎㅎ