[TIL] 세션 인증과 토큰 인증 방식

인증과 인가

인증 :  유저 확인 절차

           ex) 로그인 , 회원가입

인가 : 해당 유저가 적절한 권한을 가지고 있는 지 확인

           ex) 글 수정 , 삭제 등 권한이 필요한 작업들

 

HTTP의 특성

HTTP는 기본적으로 상태를 저장하지 않는 stateless 특성을 가진다.

그렇기 때문에 유저의 로그인 정보 또한 기억할  수 없다.

이렇게 되면 매번 요청마다 로그인을 요구해야하는데 이는 비효율 적이다.

이를 보완하기 위해서 유저의 인증 정보를 저장하는 방식으로 세션 인증과 토큰 인증이 있다.

 

세션 인증

유저가 로그인을 하면 서버에서 세션을 생성해 해당 세션에 맞는 세션ID를 유저의 쿠키로 저장한다.

다음 요청이 들어오면 유저의 세션ID와 서버의 세션ID를 비교해서 권한을 확인하고 인가한다.

 

장점

1.  서버에 세션을 저장하기 때문에 세션 관리가 용이하다.

2.  서버에 저장 된 세션은 아무나 열람할 수 없기 때문에 보안이 안전하다.

 

단점

1. 유저의 요청이 많아질수록 서버의 부담이 커진다.

2. 서버 확장 시 세션 불일치 문제가 발생할 수 있으므로 확장성이 떨어진다.

 

토큰 인증

유저의 정보가 담긴 페이로드와 시크릿 키를 이용해서 암호화 한 토큰을 유저에게 발급한다.

유저는 발급받은 토큰을 보관해놨다가 다음 요청 시 함께 보낸다.

세션은 서버에서 저장되지만 토큰은 유저가 저장한다는 차이가 있다.

 

토큰은 세가지로 나뉜다.

1. 헤더  : 토큰을 어떻게 검증하는 가에 대한 내용

2. 페이로드 : 토큰에 담긴 사용자 정보

3. 시크릿 키 : 암호화 키

 

장점

1. 토큰을 유저가 저장하므로 상대적으로 서버에 부담이 적다. 

2. 세션 방식보다 확장성이 좋다.

 

단점

1. 긴 문자열을 보내야하므로 네트워크 트래픽을 많이 사용한다.

2. 클라이언트가 토큰을 저장하다 보니 세션보다 보안상 취약하다.

 

참고 사이트

https://velog.io/@chickenrun/%EC%84%B8%EC%85%98-%EC%9D%B8%EC%A6%9D-%EB%B0%A9%EC%8B%9D-VS-Token-%EC%9D%B8%EC%A6%9D%EB%B0%A9%EC%8B%9D%EC%9D%B8%EC%A6%9D%EA%B3%BC-%EC%9D%B8%EA%B0%80

세션 인증 방식 VS Token 인증방식(인증과 인가)

https://hudi.blog/session-based-auth-vs-token-based-auth/

세션 기반 인증과 토큰 기반 인증 (feat. 인증과 인가)